From nobody Wed Mar 3 05:43: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 DD4363A11B4 for ; Wed, 3 Mar 2021 05:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-CB1YTjZx_9 for ; Wed, 3 Mar 2021 05:43:36 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70083.outbound.protection.outlook.com [40.107.7.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E40C3A11AE for ; Wed, 3 Mar 2021 05:43:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nxbqtfoXvsl4DTFkMoDPibFHJPfl6fa7JqsQt08O3EpfPmP413bELrPTL5WEjAoz4sZGQlVIQ4MwOEyEEC8tG7BwgJIOBtlJbQDSm4UJFqc/Ga3wluMiJOs5mnUbmiLRzAogJ86hzEr4O7XKSrz0MfiR4bigo7+9Dh7rn/9PBj+pKb26ZYlC6/9AZWmAKUvFttddkklFpgwkTe3FPPSfedv56w2j9GzQcaMbViNH0zd6UIdihciUWiTLLnR8ZeDbjnHm+lM/FmeaKl/XnjkFRm0cDLE9j5DnL/n358hISf6KbDRZThX9mvpLuxNTVaZ68eMp4/x/glUVDHgPgeFPHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gq/7SFRdB3d4tqzvtXeBv2gecSKkcVHgB/Ts7vj7FMg=; b=MIN7RW46ejdrJhkTn/jNs/9x1WOKw+7rZLnxGT7dzCNE+uxaAvGkf/35kjOsRZ6WFlXZkuWv1flBr6P9eoUcw6/xPKfAWQkV2lSpDGjDN8bRI5sBSJREpE0rrbGs7erMABzf2RMr9olXL5YZ/4CfTLWBmsKmRDP2VCDkW1njvctB/gAKftdI+Lpp59qn1pSZmjhiDGoKNMy5ShHjm23SQXB5/S+wbeehzyyF+C3CzI+mRNFBzoG6FoTG+ldBBX/1E+kRWG48ub4+8FAvlMvkepGGl3imEe+9nv/NoeZHvxtJGe+l9opEJoz0ZKY13teror65AWTODPzfK2pPNxpTTA== 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=gq/7SFRdB3d4tqzvtXeBv2gecSKkcVHgB/Ts7vj7FMg=; b=SzKVxyOnN+b7OZAhj+IB5cKa5uaEy+ne1rOSyx8+NmgffU7LwQkfgzlE5RX7kcyBa6NBUMovyGWaEC8LQ3jGzF9u9tANhlT6Z31whBm4VSP53dQK8LTTc/b9Gf1Zv+CDwF9hsD9KWjHa/mpaBnqmUZ/nPEJYdp1K84500HXaAsQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0134.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:25::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Wed, 3 Mar 2021 13:43:22 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3890.030; Wed, 3 Mar 2021 13:43:22 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> Message-ID: Date: Wed, 3 Mar 2021 14:43:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uciEtqeN0RUmrBcMpZkiiHl4m2Evy9zOH" X-Originating-IP: [92.34.17.243] X-ClientProxiedBy: MN2PR20CA0055.namprd20.prod.outlook.com (2603:10b6:208:235::24) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.68] (92.34.17.243) by MN2PR20CA0055.namprd20.prod.outlook.com (2603:10b6:208:235::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Wed, 3 Mar 2021 13:43:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4e8b6160-5668-44a2-708b-08d8de4a502a X-MS-TrafficTypeDiagnostic: DB6P18901MB0134: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: g12sc5WG6eW08UeMtvmpnnIzW1znDKrpSd9itsPkGJK3U6MhAAgUZ2YEGOg95fdyMzDOHgzyA7ufnUc1eN+meGi3PKz6WfBug9tmK7pK0NEyEr1x8AG+o2B36ItWaRc9Wm2wD6TFWQkKhFqdGYyajRp6X4IAjnlf9GLOYWRIZ7dqsR14lJRc7fXOyOgGbU4de8HmdCqUAwkjc4L4S/cPWamKxjwtzr0TYrGoc80wcqsT20BzTljhTfD8EEI/XpHOH36eLggHo3jel25xUY5S2Oz9nKIx+J80f39VPX3o+9DmsXgJtVpajOwuPyNKZ/uoOFZnm4ZwI/lJQomj+gPE7gYFDd3r4o4TsEyjEIsUt54JBQamV9jZfl616FzaMXCzQSwFHIpzi2fvZoHOWwDF3uBIje5A8qWM72xeBJ8LBAiedgjGqu5n3DCLMyR0wP239w1+6atGfDMdVggnD71okWWYuIsTuVvaKMxnmyz/mV1y52EYPm9upyfgSG3D7BqmkFqwBqMOUnGb+cxYZpxKSsGy5FUo35rK4A6tZMiIEVXremN8gmCiJHW3ALw+kGA+tUS+kOoudzO4caDLoScr7/1v2xmXl5aw6G9IBW2dUZEl3oDuU71t8v48J48uyBRXdiM7TBZPzpJ6oJ4HoXlMb+P/EcpMlA+tkQKNQ3MEPRQED9If6wByGb24SqSNTFoL X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(39860400002)(396003)(346002)(31696002)(52116002)(6486002)(33964004)(235185007)(86362001)(26005)(5660300002)(6666004)(66476007)(66946007)(36756003)(31686004)(8676002)(66556008)(2906002)(66574015)(83380400001)(21480400003)(316002)(956004)(2616005)(966005)(6916009)(44832011)(16526019)(478600001)(16576012)(186003)(53546011)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ZTNBRmM2Rjl6eTY1ZWcxMUllbkhHYU93N3hjQUJYNEZZbDFnQ3k3OCszdTAr?= =?utf-8?B?S0hIMEQwSXcyUnQ2UjZZc21LRkgwMVVpWnlldDlkaWFpSlZ5ZVl1UHVCSHpP?= =?utf-8?B?NXFjeTR4c0RPb29RaHBwUFhEWEtBSENSSm9RS0pxQUUrQUVKTkkzMXhDQ2lu?= =?utf-8?B?NVRXSEpuOVZkbi9YZmlrZU9FY3RBanUwdjFIcXFJbHRYKzk0alVqSEtYaytM?= =?utf-8?B?ZlZmdFQvSmZBTllwMVh0NzhpYzJzbGY5UE5oaWprUUkzOXFTYVhTbitSbkF0?= =?utf-8?B?ejFhamlPQTlDcVNoeUNHUStvY3BaZFRRRktIeEZMTWFKQlB0MjlNWFFPSVB1?= =?utf-8?B?cjlidDJvTXdieGlMYUJKUGVIb0x6Nlh2bnAzR21wTFZGWFRMZXM4bzNsQVd5?= =?utf-8?B?OUdMOWJEY2dveUxiZmtadlFybEw3c0hzenRwcitMMFdtME5YdmUzc3hZNm10?= =?utf-8?B?aGlwSXA0OHJyZWtTOWpPTUtHSHRBNVhtcFR5V3FlTXNzOGNodkdlSlpKZGhS?= =?utf-8?B?cVhKTU8zNE1MdDNnVlJEMmVkMGRCYi9xNUIzTDBkZDd0K3VRY243dDU1RndW?= =?utf-8?B?L0lyTkFTa2dKWUFPVWtwL0ZKUFhRUEtuUlNDR3c1NVpZeTdRNUpYd3JoQ3Bk?= =?utf-8?B?ZGsyU3YvdTRTMkdXU0lVdXpBcW85aXRndXBLVy9HK3hFVUVyM3Q3RVJrZVRy?= =?utf-8?B?OEorejN5S09NQTlHbXdoSFl3eU0wYmVMYWx3L09EenplZWloOHZGcnBFSjBw?= =?utf-8?B?Sk9Pd1hycGVMbVJBQ1kyNXJJakRaWmI3VDBGT1IxZFZUWkFTaFpGUDNrbkFS?= =?utf-8?B?clh4dkMvbXBHSkxRWE5yWGs4RmVoZ1A5aTF2bHNnS04vejlhdHFQNGdyS1lL?= =?utf-8?B?Y3lmVkJBTGtIbmNDTXZGazEwdVlvZVhHQjRPV1ZlQW5DY0NhMWdRNzdqbFlH?= =?utf-8?B?SUk3TUFlZFBwNWpYRnhGOW00cjZ0b1ZMSHkzbE1GdURXMDFyVUhDZ2VOckhU?= =?utf-8?B?UWpqSkZwTEh6WjYrMnNnU3lqZVV2a1FPMzRhREpGYkErVlhaUEw1T1FZNUcx?= =?utf-8?B?Y1czL2piYVl5cy8rUmI0QU1PQi9CdkNjbS91S1NiUU4wOTNBaVdJTThGNUd2?= =?utf-8?B?akFSNVQ4K1ZHWHZQNkZoMFZtWjJQZFdxN1A5Zk5VbjY1eWN6WnAraWlCSWxG?= =?utf-8?B?dXlQeEZqTVRUL0d1bk5NWWNkSmh3bTFucEFzcXdmZG1RTmdkaDdqeDRlMlVm?= =?utf-8?B?VmVMYjNwY3ErYVBYaExlTElXNnA0QWhsTnZrNVlOYTNxcUNFYXdXYU5YZlUr?= =?utf-8?B?cEM1SUU4WlVpYnlCa0tFSktNMmNWQSsvdjV2NFMyUGl4Q2VOdDkrWXFpTUhH?= =?utf-8?B?aXFkWFM3Sy95NHM0bFdHRmVkdVhlN1lzSmcyeTNObkNGSFo3L2ozYXFZMXZM?= =?utf-8?B?NzVVS2QzZHJNQ2h3TlplMVppMVhLY1Vic0lRd3RFZEVncTVjZ21TU0dXdlRz?= =?utf-8?B?YUhJSmFvbTBhRlR3VVgwdXVVT0tMc3dPeEoyTkEvTEdQY1hab1haaHZxa3pB?= =?utf-8?B?OEwyZ0k2L29VbHJ0OTgraTlzSG1OK1dxSnkvZTllTnlOY3prTTJaT0hOY09k?= =?utf-8?B?c2ZMUE1TUG15MENtb1EwUUpxdGJlK3V4S1VMdU9SMkphS3lTdjNpZWI2disv?= =?utf-8?B?ckF5eVVmNFV5dVkzdTlWZnQ0cFNHRFpkQ1haSTlybEV5WTJrenpxdFRWR1Ja?= =?utf-8?Q?VbTiVu4q2i8OypkvbIPUb5fqiIYTHSQRSVkVByD?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 4e8b6160-5668-44a2-708b-08d8de4a502a X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2021 13:43:22.8522 (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: jW+24wHIVsObOR8biOErUk1mq2teopK7U4O/HMlAigtVrN1ZGjTPqXuqLlGFGsEt2hhDBoFMtddxQp8UWt0OHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0134 Archived-At: Subject: Re: [core] CoRE Agenda for IETF 110 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 13:43:39 -0000 --uciEtqeN0RUmrBcMpZkiiHl4m2Evy9zOH Content-Type: multipart/mixed; boundary="wPHo2GwPmJj9iDqyeOi8g1KW6SjBEOiYE"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] CoRE Agenda for IETF 110 References: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> In-Reply-To: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> --wPHo2GwPmJj9iDqyeOi8g1KW6SjBEOiYE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Some more information for the presenters. Please, upload your presentations on the datatracker [1], no later than: * Sunday, 7th of March at 23:59 UTC --- For the Monday session * Thursday, 11th of March at 23:59 UTC --- For the Friday session As announced before, the agenda for the two sessions is available at [2][= 3]. Thanks, Marco and Jaime [1] https://datatracker.ietf.org/meeting/110/session/core [2] https://datatracker.ietf.org/doc/agenda-110-core-sessb/ [3] https://datatracker.ietf.org/doc/agenda-110-core-sessa/ On 2021-02-24 18:15, Marco Tiloca wrote: > Dear all, > > An agenda based on what has been submitted and on recently ongoing=20 > activities is available at: > > [Day1] > https://datatracker.ietf.org/doc/agenda-110-core-sessb/ > > [Day2] > https://datatracker.ietf.org/doc/agenda-110-core-sessa/ > > > Those who want to run slots, please: > > - check the objectives we have guessed, or provide alternative ones > - check that the estimated time for the slot is ok > - confirm who should run which slot, or provide an alternative > - send a mail with this information to core-chairs@ietf.org > > Please, come back to us also if you think there should be a slot on a=20 > topic/document which is not included. > > Best, > Marco and Jaime > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --wPHo2GwPmJj9iDqyeOi8g1KW6SjBEOiYE-- --uciEtqeN0RUmrBcMpZkiiHl4m2Evy9zOH Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmA/knUFAwAAAAAACgkQ7iZktA5Y2kMt RggAn2x4m4Fv1C0YrllmK8VrMlEv5K7+GqXjQ9Wjnqv0eNEQ+TtiYKAGgijYPSmCO6+5+ak1c7yz GxFuBfyZHnpLx8R0koekWwTBS3U+ePzUFFrPOSz2IW7O56YoIP1VVLx46rIFA+EPj43OjttA2nTc OTFNVtAfi1MMFXl2htmviBeWE6iRzWHE/czr2a2b5c2wREmucLxqJVy8PAe9pd/BiLIGqU99ZpS7 yq90B0gbj823Ndv52kYHjg5Y7tLQAXAHPwTtwKpIT+pMTHicjmeuYs/TJmp/Mxfb+ldcJoE4Fdye vy1EqCEW9phTQZF9bckaTlAED3VhpW1aslCHIqvSzg== =Ev1s -----END PGP SIGNATURE----- --uciEtqeN0RUmrBcMpZkiiHl4m2Evy9zOH-- From nobody Sun Mar 7 09:00: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 781AA3A1949; Sun, 7 Mar 2021 09:00: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 3RCiCgC5UH0T; Sun, 7 Mar 2021 09:00:48 -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 61AA13A1910; Sun, 7 Mar 2021 09:00:48 -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 8B48740897; Sun, 7 Mar 2021 18:00:45 +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 0441ED3; Sun, 7 Mar 2021 18:00:44 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:73a1:128f:55bf:b6cf]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 909A210A; Sun, 7 Mar 2021 18:00:43 +0100 (CET) Received: (nullmailer pid 3219855 invoked by uid 1000); Sun, 07 Mar 2021 17:00:43 -0000 Date: Sun, 7 Mar 2021 18:00:43 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Benjamin Kaduk Cc: Carsten Bormann , Jaime =?iso-8859-1?Q?Jim=E9nez?= , core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG , core@ietf.org Message-ID: References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <20210227205638.GJ21@kduck.mit.edu> <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> <20210227213759.GN21@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TnqGgIUpo1AhH34/" Content-Disposition: inline In-Reply-To: <20210227213759.GN21@kduck.mit.edu> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 17:00:52 -0000 --TnqGgIUpo1AhH34/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ben, Carsten, On Sat, Feb 27, 2021 at 01:37:59PM -0800, Benjamin Kaduk wrote: > On Sat, Feb 27, 2021 at 10:01:35PM +0100, Carsten Bormann wrote: > > > use "authoritative" instead of > > > "authorized" in the couple places I indicated > >=20 > > Authoritative sounds like it is an intrinsic property of the source. > > Authorized means that the specific policies that apply to the consumer = authorize use of the source for the purpose at hand. > > So I think this substitution should not occur lightly. >=20 > When the data in question is "what resources are available at this host",= I > think authoritative is pretty intrinsically a property of the host itself= :) >=20 > Now, if the question was "what resources are supposed to be at this host > that I'm allowed to use?", your considerations become quite relevant. After several attempts to phrase the text to reflect that sentiment, I am now of the opinion that that getting this picture over in a fashion that is both comprehensible and correct takes more explanation than is helpful for understanding RD at large. Distinguishing between what a requires authorization and what is authoritative information implies making a call on what is factual information and what is an assertion on a resource, and these depend on the semantics of the individual attributes which can not be done universally: * A statement on a resoure like the attribute <...>;trustworthy=3Dyes is an assertion on which the ultimate authority is with the entity defining the security policies.=20 * An attribute like <...>;rt=3D"...:firmware" is factual in a sense (after all, what a malicious party hosts there is *some* firmware) but also the prime example of something that needs additional authorization to state. * A statement like the plain "" is factual and can thus authoritatively be claimed by the endpoint. Still, some applications (not those we define because we adhere to BCP190) may ascribe semantics to it that need more authorization than just relaying a factual statement. Pitting all those on the term "authorized" is admittedly pulling in aspects of authority, but plucking them apart would help neither the casual nor the careful reader. Hoping that this contributes to your satisfaction with the now-to-be-submitted -28 BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --TnqGgIUpo1AhH34/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmBFBrgACgkQOY0REtOk veE00Q/9Htezu4Ig10Kiz0pkLa0CKloCX9GD4w682Qp0h0q4h0jOX9BNn2apldy8 NO/HD9nSLrxRh955rLN3GSIGChjH0t39iZOwsXMW8ZmbmxF+F+tjoYgt1FaLx0VD xG94YdKWSSJ/3XDV8NhRqfRsqwiGZxT/3eki4klfDpNbiMhNuWTEJLxe1mlZBmHg yMpdQAJ/1KuUiE+HQjJzFC7ZDgFW0bG0pJ66TnNwUQEWNiPkRkAAlB6/THHGBfUS R/1opvCUTYhyX9I3zaqtNygKF8mGpUMOa4adbwzRuvMIsdAKcPAxgwgncg9A0Tnm PbFyUhUigc+7jgmNVj1Y2kqds06E7s+OIFS1u/pKKpI6EVT5ejZICnFFfWqzKuY7 GN1XP6SitB0jAPUd1U5Rk2QzR6/uFAPi6CyoccVRbBAHTyNKRBOzsrMC7X1KAh82 CXqx5ybjMN7Tjvr8MiQAgdAttwiFKkft6dvnAZNUdlarnPnVVArnDrIwaiqZowtS u84dixXLWJIA1MvTHz62FJK5aijEsNu02y0GXEPNofNWu5UNeVOBC88wXR37vSnK Tg8PRqXxyPp3tcGOThYaJZNQo4IKfCovAz1g0QpPApXRgt2C/lJSHrfrSuN/XhT6 4vQnSH6IH94bI25AlKHyTpWWcp4bNY/QDZTJIF3djNRIrlCVY0o= =vdlW -----END PGP SIGNATURE----- --TnqGgIUpo1AhH34/-- From nobody Sun Mar 7 09:05:23 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9E3A195A; Sun, 7 Mar 2021 09:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_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 HPJio7hAVNzJ; Sun, 7 Mar 2021 09:05:18 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228E43A1959; Sun, 7 Mar 2021 09:05:18 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DtnsS3bkFzyTH; Sun, 7 Mar 2021 18:05:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Sun, 7 Mar 2021 18:05:16 +0100 Cc: Benjamin Kaduk , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG , core@ietf.org X-Mao-Original-Outgoing-Id: 636829515.991243-981cd7c51e2f42ec519946489542c209 Content-Transfer-Encoding: quoted-printable Message-Id: <5C49F699-D708-420F-9CBC-2A6137EEE84A@tzi.org> References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <20210227205638.GJ21@kduck.mit.edu> <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> <20210227213759.GN21@kduck.mit.edu> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 17:05:22 -0000 On 2021-03-07, at 18:00, Christian Ams=C3=BCss = wrote: >=20 > Pitting all those on the term =E2=80=9Cauthorized=E2=80=9D=20 There is no spoon, only ever assertions about it, so I agree with this = approach. (The trick is to find out which assertions a party believes are = authoritative/authorized, but this is indeed out of scope for this = document.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 7 09:38:58 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 4EAF53A19DE; Sun, 7 Mar 2021 09:38:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161513873125.19569.4977015328343482013@ietfa.amsl.com> Date: Sun, 07 Mar 2021 09:38:51 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-28.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 Mar 2021 17:38:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoRE Resource Directory Authors : Christian Amsüss Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-28.txt Pages : 88 Date : 2021-03-07 Abstract: In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 7 09:52:19 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBDB3A1A15; Sun, 7 Mar 2021 09:52: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 KiFr9aW4DHQa; Sun, 7 Mar 2021 09:52:14 -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 7DA0E3A1A13; Sun, 7 Mar 2021 09:52:14 -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 E678840897; Sun, 7 Mar 2021 18:52:10 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2D7D3D3; Sun, 7 Mar 2021 18:52:10 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:73a1:128f:55bf:b6cf]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C233310A; Sun, 7 Mar 2021 18:52:09 +0100 (CET) Received: (nullmailer pid 3226787 invoked by uid 1000); Sun, 07 Mar 2021 17:52:09 -0000 Date: Sun, 7 Mar 2021 18:52:09 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Barry Leiba Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Message-ID: References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F2RYuIB5t1AQGBJk" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 17:52:17 -0000 --F2RYuIB5t1AQGBJk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Barry, hello authors, On Fri, Feb 26, 2021 at 10:45:19AM -0500, Barry Leiba wrote: > Let's just wait until you post a revision, so it's easier on the RFC > Editor. It won't make very much difference in publication time. >=20 > Please post as soon as the tool opens again, and I'll make sure I > process it before I officially leave the AD role. The -28 version contains fixes for the remaining points of Ben's review as well as an additional capitalization fix. The latest thread does contain some remarks he made that did not result in a text alteration, but I think were adaequately responded to. For as far as I am concerned, this is good to proceed. Best regards Christian --- changes from -27 to -28 * Security policies / link confidentiality: Point out the RD's obligations that follow from such a policy. * Simple registration: clarify term "regular registration" by introducing it along with the reference to Section 5 * Wording fix in first-come-first-remembered * Wording fixes in RD definition * Capitalization: Consistently using "registration resource" --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --F2RYuIB5t1AQGBJk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmBFEsYACgkQOY0REtOk veHCYg/9FhLKo6pgVM2CV++m8OAUq48IxAzv8a2NqrE48G4yY40+o8mArytstR7e n1JS10nr4PcF5cFrx5/4d5HvdaP6Kri0V9R3OegD591JQN93JvBO1NBLpUWdvVp6 ZQVmA2jqKDGPbUfa+J/P1m6Go0XINvi8APz8rNnPvCGmuDyHyG5ID6IjLp67k6vs PRbfngzY4Tdpo9AGtC98hhhiaCTS0q+kYIzZi0UZfxNjm6Ow9RIH4JybfYhafmEF h5LyifGYEE0kcejVauYIeaHjnZgGw9fDh1S4BB8oRDf1LKtDEFFZLtrrxYVoZvEn GdtxDZVGckaHf4q8qRUNo6RsM/ILN0q72w27x0SEd5s31ivAw00i942JH921Zzrf xOzV6kJm0DZHLSZ7LLIAaaWX+QAKclBX8S4nlokDhRX0XKxidF2tQm1koCsH3V/x 6j6yI3oQRrqYBBmVsJGnbvEQv1nnHag+WRKXCwukGUZ0E0aq0mZt0uVhQVNin2EV 4NPhc5L+MTD5aY6CakWYP2Jp0ZVhTYzyPiyWkjgGnqdKIRw8w9BCH0o2RDaPVg7V AzY7aMLEEIRbKJfsel9Us8ghI7WVX4hYyuewjhPWnl3+rUrvoUi3X/akR40cjDqw 675lY/tBAnrvqBAXayQ3sfUrNuSxHWr4rWYfbe6sWz2C+52f8AM= =t0av -----END PGP SIGNATURE----- --F2RYuIB5t1AQGBJk-- From nobody Sun Mar 7 12:17:53 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 312AD3A1C28; Sun, 7 Mar 2021 12:17:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , barryleiba@gmail.com, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, jaime@iki.fi, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <161514827217.29123.18206295127536622@ietfa.amsl.com> Date: Sun, 07 Mar 2021 12:17:52 -0800 Archived-At: Subject: [core] Protocol Action: 'CoRE Resource Directory' to Proposed Standard (draft-ietf-core-resource-directory-28.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 Mar 2021 20:17:52 -0000 The IESG has approved the following document: - 'CoRE Resource Directory' (draft-ietf-core-resource-directory-28.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ Technical Summary In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Working Group Summary The document has been discussed in multiple IETF meetings, and there are no particular issues worth calling out. The working group has consensus on this document. Document Quality The document has gone through multiple expert reviews and there have been several implementations and interoperability events during IETF Hackathons and off-site. There are implementations made by Open Source OS makers (Mbed, RIOT, ...), several open source implementations by individuals (aiocoap, californium, ...) and versions run by companies on their products as well as several SDO (iOMA, etc) implementations that use some version of this draft. Personnel Document Shepherd: Jaime Jiménez Area Director: Barry Leiba From nobody Tue Mar 9 08:32:09 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0813A1332; Tue, 9 Mar 2021 08:32:02 -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 TjbGFAtZxpl5; Tue, 9 Mar 2021 08:31:59 -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 14DD43A1335; Tue, 9 Mar 2021 08:31:58 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id E670E40802; Tue, 9 Mar 2021 17:31:53 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 45330D3; Tue, 9 Mar 2021 17:31:52 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:737c:1818:4f9d:476f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B2D6410A; Tue, 9 Mar 2021 17:31:51 +0100 (CET) Received: (nullmailer pid 3538520 invoked by uid 1000); Tue, 09 Mar 2021 16:31:51 -0000 Date: Tue, 9 Mar 2021 17:31:51 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: supjps-ietf@jpshallow.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9IhhXOIxwYNE54lK" Content-Disposition: inline In-Reply-To: <004601d705f8$acbec250$063c46f0$@jpshallow.com> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 16:32:02 -0000 --9IhhXOIxwYNE54lK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, I've finally managed to look at the rest of the mail, only answering where I see value in it (considering the rest done): > > * CSM option: "There is little, if any, benefit of using these options > > with [reliable transports]" ... and reliable transports are the only > > thing CSMs are defined for. So why define a CSM if it's not expected > > to be useful? >=20 > [Jon] This is here for completeness. DOTS tries to use UDP, but falls ba= ck > to using TCP if unable to use UDP.=20 This document's task is to solve a particular problem. I don't see how the document becomes better by covering parts just for orthogonality's sake when there is, to quote, "little, if any, benefit" to it. There's this saying about things being good when there's nothing to remove. Keeping provisions for reliable transports in puts needless work on the reviewers and just slows down this document's progress (and if it's only because questions like this come up again and again). Unless, of course, there is both a) the intention for the DOTS use case is to go from the current (AIU: Block as baseline but using QBlock as an optimization) to QBlock as mandatory-to-implement *and* b) the bodies exceed the required-by-the-application Max-Message-Size -- then keeping reliable transports would make sense. > > * The 2.31 Continue rules: Why not send it with CON? A 2.31 Continue is > > just as compact as an ACK, and can convey to the client that all > > packages up to that point have been received, so it doesn't need to > > retransmit the earlier ones even though the corresponding ACK may have > > gotten lost. >=20 > [Jon] For DOTS, we have to have the entire conversation for the transmiss= ion > of the telemetry data as NON, as there could be a flooded pipe in one > direction because of a DDoS attack. Same topic here: Please make a choice between "we specify what we need" and "we specify the general case". We can go through how to efficiently use this with CON (both in this concrete point and in the earlier discussion on mixing NON and CON in ways that don't apply to DOTS but would be useful). My impression though is that this would require more effort and time than we have drive for in this document -- which is fine because it's special purpose. If that's not done, my opinion is that this document should focus on NON-only exchanges, and leave its use with confirmable messages and transports out of scope. A full blockwise-bis will need to do this, and will profit greatly from the discussions we've been having here. > > * The new QB2 M-bit rules depend on MAX_PAYLOADS to be agreed. But that > > agreement is SHOULD only, and even that's already stretching what I'd > > expect of a configurable CoAP parameter. >=20 > [Jon] Having the flexibility and ability to configure the actual value and > mutually agree on the new value could beneficial to DOTS (clients on low > bandwidth networks may want to tune it down as suggested as per:- >=20 > "If the CoAP peer reports at least one payload has not arrived for each b= ody > for at least a 24 hour period and it is known that there are no other > network issues over that period, then the value of MAX_PAYLOADS can be > reduced by 1 at a time (to a minimum of 1) and the situation re-evaluated > for another 24 hour period until there is no report of missing payloads > under normal operating conditions. The newly derived value for MAX_PAYLOA= DS > should be used for both ends of this particular CoAP peer link. Note that > the CoAP peer will not know about the MAX_PAYLOADS change until it is > reconfigured. As a consequence of not being reconfigured, the peer may > indicate that there are some missing payloads prior to the actual payload > being transmitted as all of its MAX_PAYLOADS payloads have not arrived." A bit of clarification may help here: Is the expectation that the peers report their stats to some management that then evaluates it and reconfigures the peers? May they do the stats on their own, unilaterally change MAX_PAYLOADS and then tell their peer? Suggested rough wording if that fits your answer: "Endpoints whose MAX_PAYLOADS are configurable can report their per-peer stats back to the source of their configuration. If between two endpoints at least one payload has not [...]. Th enewly derived value for MAX_PAYLOADS is then configured for both endpoints." > > It's also rather complicated. How is this better than a simple "M=3D1 > > means this block plus as many as you can comfortably send, where M=3D0 > > is for this one only"? >=20 > [Jon] We still need to have a concept of 'Continue' to reduce any > NON_TIMEOUT delays for every MAX_PAYLOADS for handling congestion control. > 'Continue' is used in multiple places in the draft. I would have figured that something local can be used here (like "have a short timeout that's extended and readjusted as new responses come in"), but with the above management, what's here should be fine. (If CONs were allowed, there'd be better options that don't introduce the delays -- but see above). > > * "is meant to prevent amplification attacks": Could you elaborate? A > > client permitted the use of QB2 has already some leverag on the server > > to start attacks, and would in any case (overlaps or not) only be > > permitted MAX_PAYLOADS on a single request by the server, no matter > > how it requests more than that. >=20 > [Jon] A single request, containing multiple Q-Block2 with M set and the s= ame > NUM (0 meaning all blocks is a really bad case) would otherwise (no overl= ap > protection) cause MAX_PAYLOADS to be sent, NON_TIMEOUT pause, next set of > MAX_PAYLOADS, NON_TIMEOUT pause etc. for quite some time. Request packet= of > 1k+, each Q-Block2 being 2 bytes gives 500+ requests for lots of packets. > Yes, there are NON_TIMEOUT gaps giving respite against a single request, = but > multiple requests would average things out. I understand this to imply that if duplicates were allowed to be requested the server would actually send them multiply, allowing the client to create a virtual larger resource it can "pull out" with a single request as compared to regular requests that "pull out" the resource at most once. Wouldn't have occurred to me as an implementer (I'd have only sent the union of the requested sets) -- but fair enough, thanks. > > * "then the body response SHOULD be restarted with a different ETag > > Option value": That behavior sounds like a recipe for endless running > > requests when CON is involed (which, granted, are under flow control, > > but still don't do anything useful). Given there is also a > > recommendation to keep the being-transmitted version alive, why not > > just stop the transmission? Or send just one final block of the new > > value -- and then it's up to the client to decide whether that's a > > representation it already knows (and just got a freshness statement > > for) or needs to get it as a whole again? >=20 > [Jon] My implementation maintains the cached body as per previous > RECOMMENDED statement which keeps things simple. I was then trying to co= ver > the non-cached copy case. I agree with your concern. >=20 > [Jon] From the client's perspective, ETag is opaque with no way of knowin= g a > newly seen ETag is earlier or later. If a NON (old) ETag is out of seque= nce > on arrival or there is a CON retransmit with an (old) ETag the client has= to > make a decision on seeing the (old) ETag (which may be for a single packet > that holds the whole body and hence is not in the clients history). Does > the current receipt of multiple payloads get aborted or ... when the (old) > ETag is seen? Usually there's the sequence of requests (and thus tokens) by which the client can tell older from newer; in sending Q-Block that's not given, thus see below. > [Jon] The new data length may be less than the previous payload, and so t= he > currently being transmitted block is beyond the size of the new data. >=20 > [Jon] The (needs terminating) response can be for something other than a > GET, making it a bit more problematic for the client to continue - > especially if there is non-idempotent usage. >=20 > [Jon] Two ways forward here > 1. Make previous statement a MUST and delete this statement Or 2. > OLD > If the server detects part way through a body transfer that the resource > data has changed and the server is not maintaining a cached copy of the o= ld > data, then the body response SHOULD be restarted with a different ETag > Option value. Any subsequent missing block requests MUST be responded to > using the latest ETag Option value. > NEW > If the server detects part way through a body transfer that the resource > data has changed and the server is not maintaining a cached copy of the o= ld > data, then the transmission is terminated. Any subsequent missing block > requests MUST be responded to using the latest ETag and Size2 Option valu= es > with the updated data. >=20 > [Jon] Preferences ? Both (MUST keep around as well as terminating the transmission) are fine. I'd be leaning towards the server just stopping if (or when) it doesn't have the cached version around any more as it mitigates slow loris style DoS attacks. But as said, either are fine -- they both ensure that no different ETags come on the same token unless disambiguated by an incrementing Observe option. > > * "When the next client completes building the body, any existing > > partial body transmission to the CoAP server is terminated": Just a > > note, you're already using Request-Tag, so you could leave it up to > > the proxy to try to run them simultaneously (it obviously can, as it > > already got to the point of having both request bodies loaded in > > full). The server can then still cancel one or postpone the other. >=20 > [Jon] If the proxy uses multi-plexing client logic to talk to a singular > server with a common 'CoAP session', it has to determine which body entity > to terminate - and may chose the wrong one based as timing, whereas it is > simpler to get the proxy to make the correct decision. Why does it have to terminate either? It can simultaneously receive two requests, and then simultaneously relay them. Best regards Christian PS. I'm also around the IETF gather venue for most of the meeting time, and now have a fresh memory of the state of affairs, so especially for the last point it may help to do a faster back-and-forth there (although I should be reasonably responsive with mail now too). --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --9IhhXOIxwYNE54lK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmBHovMACgkQOY0REtOk veHvcw/9FSPD0+DVcbvyADwNTBEvmCDrn8ygmfKFtVF1yVGsaXG6OND9SKHK+WzR vnd5PqrwozJITM/NLy1Oi0tuNNB0PaM80ZvBwxwSw4pyKCqIWbp9+Fmi6sV124lY Tj0G41ACwePp/XKqJ2tbwKct052bo82ZLx4+3F1XCidBx8ziyV7ut0Qfn5Q7YEqT zIETVVpGDDwavII/jykqtv8iprisuDfx3tiyG2+WLQ+LnCXDG8nd9eqY9FNGMmwr 3m+oes3Vm+zR6I5sJ11xzr0xzmymuGK/T5zLLQfed1Rr8uC39zgoqjraLVL5sKNp 4ndKGPLgVfh1/7+O3+BV25HDpFz73TFEZf275SuQDLv3c36lm9B7LExY2AVTRlfP gnhEJ9p6YdCbgIspyoFuK62K9Cq+ZjUzq4sPFydn+ZEwM7JfbUJVnui4IWxhqz1L 032eWxHmNsE7eO7L5c5UImPLJl7c3UiDnFzCFBd2XE++hKMjKH7o27WMA+RPgi8y FaxAXouB6NrN/tGm1iFb8H6ozdYgiYsnRGJuLKLYjpAIbT1I0xand5YX79KIo9Fg xUO1Wss1P0L6NGqNrK08JpAGpiZatUN6Hv9MV6woiBAF49ZVx08J8QdyC6AM45AV 5DXZvmnyRmzxp/bAqcUuViqXpc9wr6KH5gEBJvIQ5/1HTBsgbzw= =pgMg -----END PGP SIGNATURE----- --9IhhXOIxwYNE54lK-- From nobody Wed Mar 10 04:40: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 1E6733A08F9 for ; Wed, 10 Mar 2021 04:40:31 -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 deRT4QiK3KJb for ; Wed, 10 Mar 2021 04:40:29 -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 CE8393A08F8 for ; Wed, 10 Mar 2021 04:40:28 -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 2D1EE4089F for ; Wed, 10 Mar 2021 13:40:26 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 59718D3 for ; Wed, 10 Mar 2021 13:40:25 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [141.244.81.28]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0A3D517C for ; Wed, 10 Mar 2021 13:40:25 +0100 (CET) Received: (nullmailer pid 3579783 invoked by uid 1000); Wed, 10 Mar 2021 12:40:24 -0000 Date: Wed, 10 Mar 2021 13:40:24 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uD58pMNdjaSsRTkh" Content-Disposition: inline Archived-At: Subject: [core] OSCORE: clarification on protected-response requirement 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 Mar 2021 12:40:31 -0000 --uD58pMNdjaSsRTkh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, OSCORE contains this sentence: A successful response to a request with the OSCORE option SHALL contain the OSCORE option. Whether error responses contain the OSCORE option depends on the error type (see Section 8). I ask for clarification on the applicability of this statement. I think it is reasonable to clarify this (whether that's in an erratum, a piece of CoRE lore or corr-clarr I don't know): This is requirement applies to responders in which the request actually becomes subject to OSCORE processing. This clarification is relevant whenever there are options or mechanisms that occur before OSCORE processing and explicitly state that they can take effect even if there are particular other options; the prototypical example is core-oscore-edhoc. Protocols built around such options are, if the RFC8613 statement is interpreted strictly, limited to non-successful responses. For different reasons ("Don't abuse protocol errors for application errors", caching, maybe others) it makes sense to allow successful codes in responses too, and this is what the clarification is about. For example, if in EDHOC the preference should become to respond successful with an application/edhoc message (even if inside that there is an error), the response to a request POST EDHOC: M3 OSCORE:... encrypted { GET /foo } could be 2.04 Changed Content-Format: application/edhoc { error-code, ... } which is understood as a response to the EDHOC option part due to its criticality, and for the same reason understood to have ignored the OSCORE option (as processing didn't get that far anyway). I think this also be relevant for any cases of application-layer redirection (given we don't want to mint 3.xx codes for that) and protocol negotiation (nothing fleshed out yet, but knowing the boundaries will ease exploration). BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --uD58pMNdjaSsRTkh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmBIvjUACgkQOY0REtOk veEkvA//bvHaIyi8NVy2uT5qEEPQRkezoGrlgG+oKmdvUPwYkBFhQSczmiW1lA0d 7EY4JW7PaIG5ynpjAxM7gzthMjXJ5miXNNijN9BLImVub3jTTcJXNidDogOF/2E6 4jAlVfWlfIhT39H5/m0OpwnjzYXXAe6d0mmYYam4+2AYTwfZFjMG5oF4AVbe2b4C q+wQt6bQCEXPLKwIeZDixg8Y8nhMGtdKxj+rIRMoxxp98md+fsEEJlDjXp3x1hW4 SaJP8LJARC9GT+WKtRs3I1YPetWuUqwLH3yEVuycc0MmKJb4n0NjmL0P4a5PoBy4 7vlLbSIbCT0sGicLsYBs2ynikfdfZdSZ7wj2Ao6OIrBbkpmcMMAWS51RiigaxFom W7C41x7EKA7yAjquoC0+St8f7I2dCeimLEF37b25RpJbmUWCbGYv9TG/ZbreNEne 1C5jYo/B/tLYOKOGcXmzK364zmjLjY8y7ZPcC4X73Lx51vFcm4wO1N7zejxULZPl ZQWEVTX7MNI4nBICBjTUJdgr3eQbx2olXabsSJZon/KgpohV7J/puMlet376Fapb EvvmI/8HDkqelB1ED29Gswn6tatDMMhq6xJH2bmc2kTsj6rZg46aufwJfpKPKVb5 Cp3jsrGGrwWyl4LWqg3+Dl/zzJhTvKz0GFwFLCfw5OSYdxUDKSg= =cf4N -----END PGP SIGNATURE----- --uD58pMNdjaSsRTkh-- From nobody Wed Mar 10 05:42:53 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 71AAF3A07F2 for ; Wed, 10 Mar 2021 05:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADG-Oe0_sM8D for ; Wed, 10 Mar 2021 05:42:45 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B783A07EB for ; Wed, 10 Mar 2021 05:42:44 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lJz6m-00069V-TA; Wed, 10 Mar 2021 13:42:40 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> In-Reply-To: Date: Wed, 10 Mar 2021 13:42:42 -0000 Message-ID: <03d401d715b3$3e80d9c0$bb828d40$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYBMUDOUqj0HibQ Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 13:42:48 -0000 Hi Christian, Please see inline. Updated document changes can be found at https://tinyurl.com/new-block-latest=20 Regards Jon > -----Original Message----- > From: Christian Ams=FCss [mailto: christian@amsuess.com] > Sent: 09 March 2021 16:32 > To: supjps-ietf@jpshallow.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello Jon, >=20 > I've finally managed to look at the rest of the mail, only answering = where I > see value in it (considering the rest done): [Jon1] Thanks for getting back as well as confirming. >=20 > > > * CSM option: "There is little, if any, benefit of using these = options > > > with [reliable transports]" ... and reliable transports are the = only > > > thing CSMs are defined for. So why define a CSM if it's not = expected > > > to be useful? > > > > [Jon] This is here for completeness. DOTS tries to use UDP, but = falls > > back to using TCP if unable to use UDP. >=20 > This document's task is to solve a particular problem. I don't see how = the > document becomes better by covering parts just for orthogonality's = sake > when there is, to quote, "little, if any, benefit" to it. >=20 > There's this saying about things being good when there's nothing to > remove. Keeping provisions for reliable transports in puts needless = work on > the reviewers and just slows down this document's progress (and if = it's only > because questions like this come up again and again). >=20 > Unless, of course, there is both a) the intention for the DOTS use = case is to > go from the current (AIU: Block as baseline but using QBlock as an > optimization) to QBlock as mandatory-to-implement *and* b) the bodies > exceed the required-by-the-application Max-Message-Size -- then = keeping > reliable transports would make sense. >=20 [Jon1] Removed references for the CSM as Q-Block support can still be detected as per CON testing. > > > * The 2.31 Continue rules: Why not send it with CON? A 2.31 = Continue is > > > just as compact as an ACK, and can convey to the client that all > > > packages up to that point have been received, so it doesn't need = to > > > retransmit the earlier ones even though the corresponding ACK = may > have > > > gotten lost. > > > > [Jon] For DOTS, we have to have the entire conversation for the > > transmission of the telemetry data as NON, as there could be a = flooded > > pipe in one direction because of a DDoS attack. >=20 > Same topic here: Please make a choice between "we specify what we = need" > and "we specify the general case". >=20 > We can go through how to efficiently use this with CON (both in this > concrete point and in the earlier discussion on mixing NON and CON in = ways > that don't apply to DOTS but would be useful). My impression though is that > this would require more effort and time than we have drive for in this > document -- which is fine because it's special purpose. If that's not done, my > opinion is that this document should focus on NON-only exchanges, and > leave its use with confirmable messages and transports out of scope. [Jon1] Yes, DOTS environment requires NON when attacks are taking place. = The consequences of using CON only or reliable transport only with Q-Block = need to be brought out and so at that level need to be in scope. [Jon1]I have added to the disadvantages section " Mixing of NON and CON during requests/responses using Q-Block is not supported." >=20 > A full blockwise-bis will need to do this, and will profit greatly = from the > discussions we've been having here. [Jon1] Absolutely agree. And then we can work through mixing NON/CON = etc. >=20 > > > * The new QB2 M-bit rules depend on MAX_PAYLOADS to be agreed. But > that > > > agreement is SHOULD only, and even that's already stretching = what I'd > > > expect of a configurable CoAP parameter. > > > > [Jon] Having the flexibility and ability to configure the actual = value > > and mutually agree on the new value could beneficial to DOTS = (clients > > on low bandwidth networks may want to tune it down as suggested as > > per:- > > > > "If the CoAP peer reports at least one payload has not arrived for > > each body for at least a 24 hour period and it is known that there = are > > no other network issues over that period, then the value of > > MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and = the > > situation re-evaluated for another 24 hour period until there is no > > report of missing payloads under normal operating conditions. The > > newly derived value for MAX_PAYLOADS should be used for both ends of > > this particular CoAP peer link. Note that the CoAP peer will not = know > > about the MAX_PAYLOADS change until it is reconfigured. As a > > consequence of not being reconfigured, the peer may indicate that > > there are some missing payloads prior to the actual payload being > transmitted as all of its MAX_PAYLOADS payloads have not arrived." >=20 > A bit of clarification may help here: Is the expectation that the = peers report > their stats to some management that then evaluates it and reconfigures = the > peers? May they do the stats on their own, unilaterally change > MAX_PAYLOADS and then tell their peer? >=20 > Suggested rough wording if that fits your answer: "Endpoints whose > MAX_PAYLOADS are configurable can report their per-peer stats back to = the > source of their configuration. If between two endpoints at least one > payload has not [...]. Th enewly derived value for MAX_PAYLOADS is = then > configured for both endpoints." [Jon1] Updated draft for this para reflects that this is out of scope. However the Note: of 3 paras previous does indicate how DOTS does this. >=20 > > > It's also rather complicated. How is this better than a simple = "M=3D1 > > > means this block plus as many as you can comfortably send, where = M=3D0 > > > is for this one only"? > > > > [Jon] We still need to have a concept of 'Continue' to reduce any > > NON_TIMEOUT delays for every MAX_PAYLOADS for handling congestion > control. > > 'Continue' is used in multiple places in the draft. >=20 > I would have figured that something local can be used here (like "have = a > short timeout that's extended and readjusted as new responses come = in"), > but with the above management, what's here should be fine. (If CONs = were > allowed, there'd be better options that don't introduce the delays -- = but see > above). [Jon1] I agree that in the general case use of CONs simplifies a lot of things in terms of delays etc. (but there is potential for other = confusion when mixing NON/CON), but when forced to use NONs as DOTS is, we have to = go with this. >=20 > > > * "is meant to prevent amplification attacks": Could you = elaborate? A > > > client permitted the use of QB2 has already some leverag on the server > > > to start attacks, and would in any case (overlaps or not) only = be > > > permitted MAX_PAYLOADS on a single request by the server, no = matter > > > how it requests more than that. > > > > [Jon] A single request, containing multiple Q-Block2 with M set and > > the same NUM (0 meaning all blocks is a really bad case) would > > otherwise (no overlap > > protection) cause MAX_PAYLOADS to be sent, NON_TIMEOUT pause, next > set > > of MAX_PAYLOADS, NON_TIMEOUT pause etc. for quite some time. > Request > > packet of > > 1k+, each Q-Block2 being 2 bytes gives 500+ requests for lots of packets. > > Yes, there are NON_TIMEOUT gaps giving respite against a single > > request, but multiple requests would average things out. >=20 > I understand this to imply that if duplicates were allowed to be = requested > the server would actually send them multiply, allowing the client to create a > virtual larger resource it can "pull out" with a single request as compared to > regular requests that "pull out" the resource at most once. Wouldn't = have > occurred to me as an implementer (I'd have only sent the union of the > requested sets) -- but fair enough, thanks. [Jon1] No problem - we cannot assume a rogue client will obey the = rules... >=20 > > > * "then the body response SHOULD be restarted with a different = ETag > > > Option value": That behavior sounds like a recipe for endless running > > > requests when CON is involed (which, granted, are under flow control, > > > but still don't do anything useful). Given there is also a > > > recommendation to keep the being-transmitted version alive, why = not > > > just stop the transmission? Or send just one final block of the = new > > > value -- and then it's up to the client to decide whether that's = a > > > representation it already knows (and just got a freshness = statement > > > for) or needs to get it as a whole again? > > > > [Jon] My implementation maintains the cached body as per previous > > RECOMMENDED statement which keeps things simple. I was then trying = to > > cover the non-cached copy case. I agree with your concern. > > > > [Jon] From the client's perspective, ETag is opaque with no way of > > knowing a newly seen ETag is earlier or later. If a NON (old) ETag = is > > out of sequence on arrival or there is a CON retransmit with an = (old) > > ETag the client has to make a decision on seeing the (old) ETag = (which > > may be for a single packet that holds the whole body and hence is = not > > in the clients history). Does the current receipt of multiple > > payloads get aborted or ... when the (old) ETag is seen? >=20 > Usually there's the sequence of requests (and thus tokens) by which = the > client can tell older from newer; in sending Q-Block that's not given, thus > see below. [Jon1] OK >=20 > > [Jon] The new data length may be less than the previous payload, and > > so the currently being transmitted block is beyond the size of the = new > data. > > > > [Jon] The (needs terminating) response can be for something other = than > > a GET, making it a bit more problematic for the client to continue - > > especially if there is non-idempotent usage. > > > > [Jon] Two ways forward here > > 1. Make previous statement a MUST and delete this statement Or 2. > > OLD > > If the server detects part way through a body transfer that the > > resource data has changed and the server is not maintaining a cached > > copy of the old data, then the body response SHOULD be restarted = with > > a different ETag Option value. Any subsequent missing block requests > > MUST be responded to using the latest ETag Option value. > > NEW > > If the server detects part way through a body transfer that the > > resource data has changed and the server is not maintaining a cached > > copy of the old data, then the transmission is terminated. Any > > subsequent missing block requests MUST be responded to using the > > latest ETag and Size2 Option values with the updated data. > > > > [Jon] Preferences ? >=20 > Both (MUST keep around as well as terminating the transmission) are = fine. > I'd be leaning towards the server just stopping if (or when) it = doesn't have > the cached version around any more as it mitigates slow loris style = DoS > attacks. But as said, either are fine -- they both ensure that no different > ETags come on the same token unless disambiguated by an incrementing > Observe option. [Jon1] The -07 draft version has gone with the latter. >=20 > > > * "When the next client completes building the body, any existing > > > partial body transmission to the CoAP server is terminated": = Just a > > > note, you're already using Request-Tag, so you could leave it up = to > > > the proxy to try to run them simultaneously (it obviously can, = as it > > > already got to the point of having both request bodies loaded in > > > full). The server can then still cancel one or postpone the = other. > > > > [Jon] If the proxy uses multi-plexing client logic to talk to a > > singular server with a common 'CoAP session', it has to determine > > which body entity to terminate - and may chose the wrong one based = as > > timing, whereas it is simpler to get the proxy to make the correct decision. >=20 > Why does it have to terminate either? It can simultaneously receive = two > requests, and then simultaneously relay them. >=20 [Jon1] OK - taking your suggestion. So if there are 2 clients talking directly to a server and updating the same resource using Q-Block1, whichever body arrives last wins by overwriting the just updated = resource received by the first client to succeed - Fine. With an interim proxy = that maintains secondary/upstream "CoAP Sessions" to the server, then the = same is true at the server - the last wins - But. Let's say Client 1 is first = to the server and client 2 is the last. So, the server representation for resource is "Client 2". However, the representation of the resource on = the proxy could be "Client 1" or "Client 2" depending on the timing (and any recovery) of data flowing over the secondary/upstream "Session(s)". = Then a subsequent request for this resource could end up being "Client 1" or "Client 2" version if the proxy just elects to respond. [Jon1] Hence why the proxy needs to decide what to do (i.e. terminate = one of the concurrent updates).=20 >=20 > Best regards > Christian >=20 > PS. I'm also around the IETF gather venue for most of the meeting = time, and > now have a fresh memory of the state of affairs, so especially for the last > point it may help to do a faster back-and-forth there (although I = should be > reasonably responsive with mail now too). >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom From nobody Wed Mar 10 22:41:49 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D14F3A12BC; Wed, 10 Mar 2021 22:41:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shawn Emery via Datatracker To: Cc: core@ietf.org, draft-ietf-core-yang-cbor.all@ietf.org, last-call@ietf.org, semery@uccs.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161544490805.3198.4896668099907204116@ietfa.amsl.com> Reply-To: Shawn Emery Date: Wed, 10 Mar 2021 22:41:48 -0800 Archived-At: Subject: [core] Secdir last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 06:41:48 -0000 Reviewer: Shawn Emery Review result: Has Nits This standards track draft specifies YANG modules for Concise Binary Object Representation (CBOR) encodings. The security considerations section does exist and refers to RFCs 8949 and 7950 for underlying security issues. It continues that there are no additional security concerns introduced by this draft outside of any specific context or protocol. I agree with this assertion. I also don't know how pedantic we should be in including the YANG module security considerations template to a draft that does not specify modules specific to a protocol, i.e. writable nodes, sensitive readable nodes, and RPC operations. I defer this decision to the security ADs. General comments: None. Editorial comments: None. From nobody Wed Mar 10 23:45: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 B42853A145C for ; Wed, 10 Mar 2021 23:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DqSsMHYbSviy for ; Wed, 10 Mar 2021 23:45:08 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50064.outbound.protection.outlook.com [40.107.5.64]) (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 00BED3A145B for ; Wed, 10 Mar 2021 23:45:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kyakDXY9QkKtaexL5YxzAIXmAuvuZaK3s8pW/xjt0CH9HqmKUj6DgOlA3iVldhpqjepNbQZ6gEJlrZdSJODN5oUH7cEgkG/YEGVZH2ILk+F4lbR5jJyx73xfil48rLyImyr2FZSkHtdRIEZU+yZAKLWOEgmEjmnJnYqr3ihl2VcwS9uSZauH0sTTLAUXTHeeCnsHuj9Z0yO0mBHEg0pnFJf9xGADua252wB+kCNCnbLOd9j2MEhZMT3LEF/Z1dNqY5GIhFeDhGBMa+ORcXHC2+2ETiPGB5pcyC3qo97Vc+G9XqufMNBrgqu1px99ESUkNUEFQUJpx34gJKvJguY++A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GhKR+I4XOIsOm1uhLfG5QueNiZUxd/aT/nrDevDeR5c=; b=m8Yh6ccTn0TKXsWdKimrC85IZwWlaM8GUPHtQlN3DPclI9+2zsOoqOg71qpmI7bcaMZF8foudhYKzB5c83DBtS+KtRnmOTdBqcCtTjRVk8o2S4i2DiNY1RKxH7ixPImZyUNCl24tiovoqREn/4oymMu1QueifKBctECOmbywWPhr6Sq8iApYWVvbOabWkv2JuZA1UqIY0ccqSDssGgVZ+s4o/l9shkTSl6ZoE4tfGiU22LtrctGAehqCg3hiPR38Dz8j9l14aHaOgrCP+9jQTmez/fNMhsKZ5Y7GqlRUy7pg4HvWDJAUrBX1GMvZA/GXwZVtG4lTNvwHvFe4wv7h2A== 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=GhKR+I4XOIsOm1uhLfG5QueNiZUxd/aT/nrDevDeR5c=; b=Kxdn2w8STNSj5vD38bmR1jxFl2JFvxUNu7nebX/koGQnmeSAn/Qpfpa7zafmKkDk+uAQSazxqBAHeEcCFjjK+8PwRW/MhginfICG7+gY7GHBXdM4xrH8nihkC0/dmq+j+S9CIKogXgMWotiOGz4I10wLqwbxvk66wOdk8A+fDJo= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0072.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Thu, 11 Mar 2021 07:45:04 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3933.031; Thu, 11 Mar 2021 07:45:03 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> Message-ID: Date: Thu, 11 Mar 2021 08:44:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E6u5afGumsE739Ri3WbykdUtefd3kgZgb" X-Originating-IP: [92.34.17.243] X-ClientProxiedBy: MN2PR20CA0062.namprd20.prod.outlook.com (2603:10b6:208:235::31) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.68] (92.34.17.243) by MN2PR20CA0062.namprd20.prod.outlook.com (2603:10b6:208:235::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Thu, 11 Mar 2021 07:45:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bcf16880-493d-4ea6-c03e-08d8e46194ff X-MS-TrafficTypeDiagnostic: DB6P18901MB0072: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: s23YNGHTlQ3Yr7Io/S7R+FMAHOe8UbQNwARFNKUhvhEFYABOdEg2rCnMhLqvqzXx8T4hhuD2y8jcAsgC4a6rElXn+4CBY9PC+Zp5fg5JxBNR0b8RET7iYQSBMBcfhUKsXvHZG0O8DA0zbIXL5HuIzHr2oVpqW5Nstc0afHBcunYYz3YfUh3AJ1ThQ5zmtDbKKgsGFI1zhnIpruSVt7/WFsK+SqLFIhcmBH19eO6/xGcfv4v3yj1m5D3kg3dmYABVG+iM21skWmx8nTF+lxE8gXEUJ1RdQYasD1LPnzuk2a/s7G54C86N2QW5KoUJjLR2ANbu1Epq3uYRT/YocRwmmmrpC6X1E9Xzkj5UhUfOpDR6L2whqt35mllifbZjlhcM56MOCxPMBpKmtWbJ4p8UhuUiNmh4+O0RJKIrg1c2c2wLcp76QDgBbNN+yHYATEbbeC8ERhd5J6hWTbkESFT8+dOj2+bpjBCs8CjDBNmJAa+8BjAPFJnXK1OPvjjwTSUbmTm3DscVRUHDfjaRk0sAqvuO+wfOR+l0KogYXGuEdlL9QS2lPhzMwzlN+8kMp28PgVDNrYh01hy1qvYIJUiCbE6YZAgVpy8fRwykorhhIRnpOa/Bl9IBuPF0nRJsKxbj4yBU/mxAtSudGG/jNLoYs9QWbWvEYiS7RDB93/XfYDtcLAaSo5oQ3xptNiAKp8aD X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(396003)(366004)(39850400004)(346002)(6666004)(66946007)(6486002)(316002)(36756003)(52116002)(478600001)(6916009)(8936002)(66476007)(66556008)(31686004)(235185007)(2616005)(16526019)(53546011)(21480400003)(186003)(8676002)(31696002)(956004)(5660300002)(33964004)(26005)(2906002)(86362001)(966005)(83380400001)(66574015)(16576012)(44832011)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TGJNUytwR2VpbEd1dkU3N29CRVdITzlYUnVsdCtPNS9DYlMyM1c4UHlpTGVM?= =?utf-8?B?L3RLTHNIRDJEaDVkdDl6Y2R1WHc1SEcvZndQSjhmbm1vdjZFSU5uV2E5N0Vq?= =?utf-8?B?YmRBZmQ5Qlh0Umk4azBFTWZxZ25aenhsRWd6SEtZTUpVZWdRWkVsZTh6QWI1?= =?utf-8?B?bjJsUG9IUHZCZXZ4TGRXakNmVXhjZU9TRFRVWlcycEtFSjBuellTK3Jtd2JD?= =?utf-8?B?Vkh5LzZKNjJEZjQ1a3hXczFIVGJHWmZyMGlFVjlCU2hyWkdSVEtEdHEwaG4y?= =?utf-8?B?SFpUVDdnWFo2REJldHBXcGthVXRKQkJGUkpBdGVIWmZRRVJHdnA4VnU1UDJ0?= =?utf-8?B?Y04ySlQ5UTVHeTZvaVlvc1FGSkxrOGwrZ1JKYlRHY3o0bnBDK3gwYysvUU1U?= =?utf-8?B?YmZaUTdtZWR3b00xNENncnErVU1OZU1VWDN0RXpyOElDQlF0OEJRQ1VCWjBk?= =?utf-8?B?UzhZODlpUFkzNDhZZG5WR2lNN0NxcENUVWQ3Y2FiaVRxcU9oTkJuYnNGbTRD?= =?utf-8?B?R2VSV0h5NStpMXY3SzBVTkJoUXgzVTVud0RCaGtISzRBeUtveUFUV0hOcTdM?= =?utf-8?B?U3lSY1B4VVRkOE45ek55NjNvTzUyNUw0ZFFWUFNwOWRFVmRNZldHVmdTYkZJ?= =?utf-8?B?ZDJVYzBHWSs4MVM3Vklvc0NSYVlRVUF2cjFLbE11Z01rNUs1bHZtVzlzOTlB?= =?utf-8?B?QVVQY1JPWG0rZGM0UUxRMyt6TzJJOTkwM0lubXhJaVZIdnFkUmpWakViMzd4?= =?utf-8?B?RTltS3ZXZlI4K0VmV1YxOENJc2pCd25jcXRDc2dXdU9PU092T0E3Sm1Oa09Y?= =?utf-8?B?Vy96SUtLVU1IT2c1UERXeTVrQTRKMmRNZ1NOWXlhejhmT3U5TExBY3Brb01M?= =?utf-8?B?ZXMrRzl0eFJmN09KQlBIZEZlbm1iUCtzcU5wYzIzaEZWVUwzY3RxenNtNjFM?= =?utf-8?B?VWQrZzRYQlVpVW5JWSttYXEvVGJlZnFlOUV4WVl0SUtuMU1XV0hRTUNHQW9W?= =?utf-8?B?blVLMk9hMWY2RXpQeFh6M0d3QitaV0kvSmZTV29mVXVNNkk0N0YvU25LNjFT?= =?utf-8?B?czRWdFFLWmYyMXhoWGZIWmttaDF0VjgwdExFbDNoNU5Rc3E0VWxmc0NxTG1X?= =?utf-8?B?akFjQ3g1SkEyL3dINWMvU1FraWNObmdrWHFNYngyV1V6b01zWWtPN0pvR1dG?= =?utf-8?B?NXRvWU9wa3B5ck5DdlRBVTVyYkViVjNid0hEZUk2dmY4TkpoQTVxblJZUGh4?= =?utf-8?B?alp1ZlFhb0JWNmlOcmsxeG5GUzhwWHhrU3BMVmwyYXhCZitSUDJHV3Nvanp6?= =?utf-8?B?QkJnMjh3Y3MwSWt1M1N6UENRWkZoRVZOc2l5d0l2L2JCcW5pRUY5VzhHSEJo?= =?utf-8?B?K3E5RGgwMlBwcytIQWNSaHZKc2YwQUgyR2hGZGJhRDBGbVk0NHdSOFhHMDhl?= =?utf-8?B?VGJyVVJkUTNCMlNXeFJjYzZPb0d6andmbWczeXFkWm1wSFpMamlGeExpdU1O?= =?utf-8?B?V2V6T3hFZWVRYytwYmJwNGl6MUZpdHRFTGpXYVY0WDBXQXdkbnBPWEFkNzFK?= =?utf-8?B?UnB2UDRRN3J2N0NPM2IyWVYvTDVZZ3NYcG1hWFd2dyt2TWhWNkNaMVo5dGwy?= =?utf-8?B?VWMrZ3gycmFjYm81QnhWZ2hSQ29PMEliSWpnanA0dHlvMEZSYUZrTFVRV1Q5?= =?utf-8?B?ZGVqVGFKSmd0eTd0TjZKN05jZ2xNemE3cXU1ZldVc0ZEQnI1YmFDa2NCTng0?= =?utf-8?Q?JkAwFkpvMvDbgxNTREN7pKuxhYCQ13RRQWFSVvQ?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: bcf16880-493d-4ea6-c03e-08d8e46194ff X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2021 07:45:03.7884 (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: u/xH7AwpXfl6jSKubsgaUqHA4BP01k+4x5xFuWdIJTVeVNHSaBKAE3ouXCQnQq3zl5cLPH1qou8gj0zxTknc5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0072 Archived-At: Subject: Re: [core] CoRE Agenda for IETF 110 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 07:45:12 -0000 --E6u5afGumsE739Ri3WbykdUtefd3kgZgb Content-Type: multipart/mixed; boundary="ulrUyiR8xttLFnOwlq96kEQ70yjussRlY"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] CoRE Agenda for IETF 110 References: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> In-Reply-To: --ulrUyiR8xttLFnOwlq96kEQ70yjussRlY Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a kind reminder to the presenters of the Friday session [1]. Please, upload your presentations on the Datatracker [2], no later than=20 today (Thursday). Thanks to those who have already uploaded their slides! Best, Marco and Jaime [1] https://datatracker.ietf.org/doc/agenda-110-core-sessa/ [2] https://datatracker.ietf.org/meeting/110/session/core On 2021-03-03 14:43, Marco Tiloca wrote: > Dear all, > > Some more information for the presenters. > > Please, upload your presentations on the datatracker [1], no later than= : > > * Sunday, 7th of March at 23:59 UTC --- For the Monday session > > * Thursday, 11th of March at 23:59 UTC --- For the Friday session > > > As announced before, the agenda for the two sessions is available at=20 > [2][3]. > > Thanks, > Marco and Jaime > > [1] https://datatracker.ietf.org/meeting/110/session/core > [2] https://datatracker.ietf.org/doc/agenda-110-core-sessb/ > [3] https://datatracker.ietf.org/doc/agenda-110-core-sessa/ > > On 2021-02-24 18:15, Marco Tiloca wrote: >> Dear all, >> >> An agenda based on what has been submitted and on recently ongoing=20 >> activities is available at: >> >> [Day1] >> https://datatracker.ietf.org/doc/agenda-110-core-sessb/ >> >> [Day2] >> https://datatracker.ietf.org/doc/agenda-110-core-sessa/ >> >> >> Those who want to run slots, please: >> >> - check the objectives we have guessed, or provide alternative ones >> - check that the estimated time for the slot is ok >> - confirm who should run which slot, or provide an alternative >> - send a mail with this information to core-chairs@ietf.org >> >> Please, come back to us also if you think there should be a slot on a = >> topic/document which is not included. >> >> Best, >> Marco and Jaime >> > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --ulrUyiR8xttLFnOwlq96kEQ70yjussRlY-- --E6u5afGumsE739Ri3WbykdUtefd3kgZgb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmBJynoFAwAAAAAACgkQ7iZktA5Y2kNs SwgAmalG9WsjE9zKtacwB0OJIZ586+2UMMw2ALOU2xRPcCwBP1S+0OQk5PGakNyaQX0VVkVCzZky SYOYgz/ZFRG1vjSBd3TcTtt4TtFkUFsX9zvQo99HAFILtK/K13Df8h0jRdhLUTqI+tQ1HrwXzqZf TwyQbsZQ5qmk0SeuAN9uokix0/5S6FisGfjj+milxvWzGx1OAeso+CMZf3eGH2OJ+AayCyiCQ9SB GYW2ekSlbGlSeea+ZLYnvN/Mlm5BdbzvJcHrE6K/r042ff1YOnM4Dk/kyRZnxT+fbrqdwmKoJReB vkix+JMTyIgr0zvGv5bWAaKrjkqYlGmo96bMjkEzAA== =mjGp -----END PGP SIGNATURE----- --E6u5afGumsE739Ri3WbykdUtefd3kgZgb-- From nobody Thu Mar 11 03:40: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 4BFB93A19E1; Thu, 11 Mar 2021 03:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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 4Vt4ir9n_9gZ; Thu, 11 Mar 2021 03:40:21 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30087.outbound.protection.outlook.com [40.107.3.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1AF3A19DE; Thu, 11 Mar 2021 03:40:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vz/VMBWrP2Kjyy5ZkAv0ah486Lxl+gxZXtyamwCXBycxBDNqWJWVvr74yL1i/eD0u2FTf9pfl8aWkMlkPcQ6KuorUhO0Lwz3B7PWBfmWrs/Y9njHZEoYdFs2cKFcqnEH8OoZvpyYT3tDr0f+4xpmX7QdRCvkl2C8e97QtAhnOLfqwbkO0PoTSytyYIhNiZs7V9JV5P/HHLztg99IW9/OyyIlEx1QyxQFr8icmIGWNZdKoGbyJHymq/PQuj29oeIppBURYWzid3QcALcu+O4rN9kdS2xAc7D7a3Jr806/dXUqc60gFCM1yJkycNaCOFoqUZX24Rs/ivXTYCVmC/67NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dbeCTxDO3QnBE8p5aGpEK9uG8cREYGAcDJs4a3iAn74=; b=WuTNkVEXRO2w5yuEiViowGz7m8zkiWfTYJjPdcXeOfcF8nNxBH5Iy9kW7fG2dk0cK6r1tTfLVCClGfOiuULg3+4S6avv374MnSk3zcAZwqywH1K4fGS0kq6gyBYzXAv96SVLk1VLT8OTtQ+jrBmLOrNHt8yhfPZnWnHGvfWeFHe6F9qgWzVu1Rpp3J0GufmEAAZZA85sN2G/KPdsG8gbyI+egUwGui/Fj3gQtBNYMGa8QlaSGVwSfbLXY6HzCuMlh7ZD0B0Dw62U6C6ArKWrFvXniaeLh01ziv9LKQoGO+lfSpmyXhu3B50YOSGqFvrpi4VcczmWYqIdrzOhwEjzaA== 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=dbeCTxDO3QnBE8p5aGpEK9uG8cREYGAcDJs4a3iAn74=; b=e0IhSSoSKKL6x4Vmx/VAqcOOrAGdlirEjjpGCHj3hiD/8X23ohIcTw3kLRK3G/9xy6xypHVVM+bnAh/gGxpdBrhH3UAPeCl6KLC43jdEmanQz4448YlbrYm0+r7GODzWtfIunGo4o7SqHILbo2nXG7h87aL/iQgPA7017puejFw= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Thu, 11 Mar 2021 11:40:05 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::69ab:83ff:dd6e:3536]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::69ab:83ff:dd6e:3536%4]) with mapi id 15.20.3933.031; Thu, 11 Mar 2021 11:40:04 +0000 From: John Mattsson To: "core@ietf.org" , Lake Thread-Topic: Analysis of AEAD limits on the SAAG agenda today Session 1, 13-15 UTC Thread-Index: AQHXFmtHh9Yye4JAkU2iitMFuAaQjQ== Date: Thu, 11 Mar 2021 11:40:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 299be1bd-6c97-4801-9e85-08d8e4826a0f x-ms-traffictypediagnostic: HE1PR07MB3209: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: euuhLSg2mQR2S3R98Uhi50AsFrxxJE7NCPFrcz1GAKKqx2j0kzdy6WEk/B5+6xjMDs/enKeF4Es+a1sw+JCOwO7xFYELKV2KWPM8uFWAPifF0agIsTZN/lxfTzewZ3WD0TweNVQO2DvUHxlXIu5nHMWgGKgKM67tIOx6Ne7ho4DznpYG8v5aJUi/Q1b9Et5djAa4zTiwTbR75UJ12eg9BUmwTUOtF7IoPd0jW7wgEwKSxgl5SsGImfudgfi69BX2n0OgRhTrcDVVBDwPfvntDf1xtvriVY+MlwD2OENkIcLsLFgYV2+b4aHw3TA8/Y5bkYrkGjMQ4LBEy5gLSoZ5Vt1yz0OSLTh7CuvPK5VhC3j1PpG4prUDDoP05WlN8Eg1GNEVUCklEes6UftuFXik8i8riMcySUrC8Ff46Gsr6+rWwaZWzOr3dduOpaP80x3K9tetGh9ybO6CITZmIZGaXZhqdlGyfdWg8jYDc77T1R3QmvfgpslES4giMC3fZV+/oDWSSWwBYbhEkBcd0MGBLT9WbDQ621pQ+XM2j6etLb2o91DxX5l6FqWAyHdU0rDMN1BlLG+hxRfg9nv9UCfBp0rdkth5+gpYm0EmJV0DEglFm4jWc2GWYbViTRjXKf8ffHWPZtJLxiC1Q8wOJbsp6Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(136003)(39860400002)(396003)(36756003)(26005)(4744005)(66946007)(186003)(6486002)(83380400001)(450100002)(6512007)(5660300002)(33656002)(8676002)(8936002)(76116006)(66556008)(966005)(2906002)(66476007)(66446008)(64756008)(2616005)(478600001)(110136005)(71200400001)(6506007)(44832011)(86362001)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TmlaSHV3SXoxRlZQa25BL1BNWjlNVVFocVhWQ3RlN2lHcDM3a0ZlbU5QdG9L?= =?utf-8?B?dC9MQVR3dHlHK2FSbjN6Zis5NG5xc3V4SjBFUkZkT1Znc1QvWEk1d1RKclpk?= =?utf-8?B?ZnhYd3ZOaXBBbklGOUIwaHVOYzJGTVVXSGRDMENGcFNabVNPZ05FYXc5NlBC?= =?utf-8?B?UFluRVV0N2Q3cm5YcGFUcDJyRVNWOUc5QmZqMDM2dm1ib0ZuQkFrTGJOd1BV?= =?utf-8?B?MlBEQk1CTXFsZDM0djR4dHpjMzZFVTdvWUJ4K0dxbjZndUVLcTNHcVljWnVk?= =?utf-8?B?Z0ZvRkFwMzBkWmNHNHB0cWVZdG4rSCtYSzZycGVrUlhVWjNxU3lodEVPZk5u?= =?utf-8?B?NjUzN2FpTmh3ZERiTVpzTzNuaEY5S0ZDSnlIS3NUZko0c1QyMDJ4alN2MWlz?= =?utf-8?B?T21GdVd1cmdjQnl4YTQ0TWR6MnJPV0tWOGZMRDBOWnhaY00zV0NDc0F6TmNO?= =?utf-8?B?LzZKM2hhdVF5Y3l5TW54TnpNWTE5VUFsN0RISUh0ZGFCaXdEbm8rV1lYMjRj?= =?utf-8?B?eWFKS3pGMHhBN1oyMTZoeHUwV0FmRXBRNE5pZDF4aWlzbWQ1UEIxdVlBbita?= =?utf-8?B?aDZ3QTlOUTF0ZGRkUitnZy80Rm51bld5RUdlYTNPekdBNkxLRmlzTVlVVWhE?= =?utf-8?B?Zk9kVFJNWi9QSTl4dElzem9zTDdtcVpvM2VESzJKTThBVlZ2QzBWbmdpR0J0?= =?utf-8?B?b1RvS1loVmdRZzY0Vzk5eEhnSHBJdGJ3aE9vVkk1N2hNdGgxQUhOS2djSlEw?= =?utf-8?B?a3BzZjFMWm5vbWxhMzJhTCtTU3lobGhmN3huUmFoRHNzT0w5MGUxUnF6ZDA4?= =?utf-8?B?bXdOVWtSdnhjQXBkd0FFVkR2czljU240aFVYMTMzNVdpZ1dJZ3NmdEJSZXRB?= =?utf-8?B?WmhhMWQyQk5nQVFKTSttYUd1dVVFVEdLOENxTUxsQkV1VGFMaE14ZERGcmdw?= =?utf-8?B?WEtmdCtnNjg3eFQzcVlrK0NpVjRwdXhybmN6MWRYcUpyVDd3cnBVU2llNGNH?= =?utf-8?B?dVdicGNVWFRWR1RaeEdYUkRlQUJWMHEzM3lYZU1BdFZXZkFuVGNIdWptamtG?= =?utf-8?B?Ymt1ZzNXOUE4SlA4S3lISStBaWNnYlM3NkwzWndYdlg3MS9VWE4vblFYTWh1?= =?utf-8?B?WTdORUlEZDJYL0Vic2k1TnlMb0d2UGlkTWZYaEN4cEs3L2pJR2tCNnVDVlZT?= =?utf-8?B?Z1N4Vms4ckFpU0V1L0FFaW1jTU9CeURQREpqSDNzZGRrdUVQL1NGK0Z3dWoz?= =?utf-8?B?TFZsem8zMzh5eFJtV2taclZhbUxmY0ZCb3NLOU1XTUwzNWVuNkFRM21peFNN?= =?utf-8?B?Sk80MGZvSDJOdDZ5bXpCZ2RlYjBQK2U5Qkh4cWZXM0Z5Zmt4cWlCckROenVm?= =?utf-8?B?SHVqQnhtVVVJQmY2SkRFWVltZFBVYjV1QkpRcGphemdaYk5CL0tXRjBuTHRE?= =?utf-8?B?dDNDbU5vYlRjWjBDR1VTVHVDRjhMRGM0K1cweEJ6ekZYb2VFbVpLbzNWV3Vi?= =?utf-8?B?LzdqYktXWkZWcEJmKzFIdWhJUndBZHdUekRjY3pzN09kMm9hQldHUFNtWWhN?= =?utf-8?B?ckZwWEZTQkNjMSt1QnA5RGZ1dk81VVhOY2ozMEZFTm5XSUt6MU8veGU1blA1?= =?utf-8?B?MDJ3SkpaKzBuNzZyM2VJdFI3WnBKYmVob0Z3a3pPOGFzVENHRVVhdXZEcHhG?= =?utf-8?B?RFpzV05qWEdhaUwySU1wVHA2Vmp6TExVVHNIODRVb0s0MHdUUU5QY29hZnFp?= =?utf-8?B?VkVTSE12Q2ZGRHc2VHhVbWV6L1BiWGFGUGhPd2MrbnVucDZ3TWdoMDNRbzB5?= =?utf-8?B?cHMrRHIzWUtxNkFhZVptZz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 299be1bd-6c97-4801-9e85-08d8e4826a0f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 11:40:04.7985 (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: hLvZsxn/Hr3ji/mok1HPptqCsKNseaUXEG1NTyntbWSjKwKNk72dVSlQ+o4/72O2N45h9T3wEcVmARSKyyIFoL3aeRvNT/XbPtDgAos2OoU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3209 Archived-At: Subject: [core] Analysis of AEAD limits on the SAAG agenda today Session 1, 13-15 UTC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 11:40:23 -0000 SGksDQoNCkZZSSwgQW5hbHlzaXMgb2YgQUVBRCBsaW1pdHMgaXMgb24gdGhlIFNBQUcgYWdlbmRh IHRvZGF5IFNlc3Npb24gMSwgMTMtMTUgVVRDLiBTdGFydGluZyBpbiAyMCBtaW51dGVzLg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTEwL21hdGVyaWFscy9hZ2VuZGEt MTEwLXNhYWctMDINCg0KTW9yZSBvZiBsZXNzIHRoZSBzYW1lIHByZXNlbnRhdGlvbiBhcyBJIHBy ZXBhcmVkIGZvciBDT1JFLCBidXQgd2l0aCBtb3JlIHRpbWUgKDIwIG1pbnV0ZXMpLg0KDQpJIHdh cyBwcmV2aW91c2x5IHJlcXVlc3RlZCB0aGF0IHRoZSBwYXJ0IG9mIHRoZSBBRUFEIGxpbWl0IGRp c2N1c3Npb24gZm9yIE9TQ09SRSBzaG91bGQgYmUgZG9uZSBpbiB0aGUgc2VjdXJpdHkgYXJlYS4g SSB0aGluayB0aGUgYW5hbHlzaXMgcHJlc2VudGVkIGlzIGFsc28gcmVsZXZhbnQgZm9yIG5vbi1P U0NPUkUgYW5kIG5vbi1Jb1QgdXNlIGNhc2VzLg0KDQpUaGVyZSBzZWVtcyB0byBiZSBpbnRlcmVz dCB0byB1c2UgQ0NNXzggd2l0aCBEVExTIGZvciBJb1QuDQpodHRwczovL2dpdGh1Yi5jb20vdGhv bWFzLWZvc3NhdGkvZHJhZnQtdGxzMTMtaW90L2lzc3Vlcy83DQoNCk1pZ2h0IGFsc28gYmUgcmVs ZXZhbnQgZm9yIG90aGVyIHNlY3VyaXR5IHByb3RvY29scyBsaWtlIFNSVFAsIElQc2VjLCBldGMu DQoNCkNoZWVycywNCkpvaG4NCg0KDQogDQoNCg0K From nobody Fri Mar 12 00:37:38 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 22EF23A1053; Fri, 12 Mar 2021 00:37:33 -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.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161553825310.17716.16864700679166967020@ietfa.amsl.com> Date: Fri, 12 Mar 2021 00:37:33 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-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: Fri, 12 Mar 2021 08:37:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-08.txt Pages : 44 Date : 2021-03-12 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 12 09:13:27 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 786883A171A for ; Fri, 12 Mar 2021 09:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW-KhIqKzU1i for ; Fri, 12 Mar 2021 09:13:22 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2286E3A1719 for ; Fri, 12 Mar 2021 09:13:22 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DxspR0sMjzyTw; Fri, 12 Mar 2021 18:13:19 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 637261998.591525-4883017c76e7482c4324ffa6c19954b5 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 12 Mar 2021 18:13:18 +0100 Message-Id: <4EA9EDD9-0B3F-44E8-A1FC-9D8E5FB392DE@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-palom?= =?utf-8?q?bini-core-oscore-edhoc-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: Fri, 12 Mar 2021 17:13:26 -0000 In the Monday CoRE meeting, we had pretty good in-room consensus to adopt draft-palombini-core-oscore-edhoc as a WG draft (Adoption call: +9, one "not raise hand" (explaining: not against, but not sure either), no opposition). As usual, we need to confirm this consensus on the list. If you are opposed to adopting this document, please speak up on this list until March 22, close of business. (No need to reaffirm consensus if you were in the meeting.) Gr=C3=BC=C3=9Fe, Carsten (stand-in WG chair for a few more hours) From nobody Fri Mar 12 09:15: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 352DC3A1725 for ; Fri, 12 Mar 2021 09:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EldKb8ZbznLW for ; Fri, 12 Mar 2021 09:15:14 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5290C3A171A for ; Fri, 12 Mar 2021 09:15:14 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Dxsrc6w76zyTw; Fri, 12 Mar 2021 18:15:12 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 637262112.489677-fa0d34acd0fd4d3bf91822451cda663b Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 12 Mar 2021 18:15:12 +0100 Message-Id: To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_Confirming_the_adoption_of_draft-t?= =?utf-8?q?iloca-core-observe-multicast-notifications-05_as_a_CoRE_WG_docu?= =?utf-8?q?ment?= 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 Mar 2021 17:15:16 -0000 In the Monday CoRE meeting, we had very good in-room consensus to adopt draft-tiloca-core-observe-multicast-notifications as a WG document = (+13 on adopting, no opposition). As usual, we need to confirm this consensus on the list. If you are opposed to adopting this document, please speak up on this list until March 22, close of business. (No need to reaffirm consensus if you were in the meeting.) Gr=C3=BC=C3=9Fe, Carsten (stand-in WG chair for a few more hours) From nobody Fri Mar 12 09:33: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 A34193A182A; Fri, 12 Mar 2021 09:33:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 II9ZBnbWD-Ir; Fri, 12 Mar 2021 09:33:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 7566C3A1826; Fri, 12 Mar 2021 09:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615570422; bh=bcdx1VI4N3/k2Usd32934iXXwOkzYxVbCWrJuHcWRdQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=kFhcAe40tFzFMRD5TdFJh7lvnOE3jBJvs1axax5D604xN7718J+Em1oD/NPjP4Ypf aKzkbYe9sygVGxEywNMzDzy+incQM1INrYKpmkl5dCtAkpl9msf6jR1Nt+4SfRzcyf TVcStEvB/3LxPxYIbx+ZCZYj/w7Wq3wKNz9LIoOg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.106] ([185.236.167.136]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTRMi-1lAuHR3kia-00TiLi; Fri, 12 Mar 2021 18:33:41 +0100 To: iccrg IRTF list , tcpm IETF list , core@ietf.org References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> From: "Scheffenegger, Richard" Message-ID: Date: Fri, 12 Mar 2021 18:33:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:E+AAzWc8NxTBG0hg2UZThsjtApmARhQLenkbMcXmCfuBB4VRqoE TccO0X2rCERJMfa431JIgyZ1RC883Vj7hH8mMG1YXPOxhvhNqhLR5FC3meWK/LBqkTgkL/2 rEpg++I8CMZ+xd4j0H+HIyhmvMeDYQFgiemaPKQBDKs765SV4uYOi5jJ7Jl/JBGFFZqt2As wG3HcrTTCVaHovfVTidhQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:/YbKT9FFnkY=:t/N6wyIe+PpJVUEtJkIUCy 1W4ioVQxWa6ubHVuAkwmh1W/9Es+9aXsXK3iNikQbpF21QuyDrBVLXvRLa/pkFeGdQ4qoWhZQ kNBlW1b2w01F9Ai7i6q137neXu300PpaQt7PaaeFZO5hFuhzmdNM0cvWBd75bkg9Uf23rCZjp supfAJ/dyvDyc/ILHkQxClaHRJvUUFM6rzn1+6pWLhJj6IbnJjduq2PByOQYxUmUS+inMW0po yvQNgNdVYxu7EoqDDCfxy5LwBcgZQPUalbtDo1FWv63pd6t90JKLV9r8xpAt2zywlludbgycA KPuvoRunVROmpaZPD2lPTIILNwivLG/E+5w+4PlQ2JdVvZOZOUggXc+KyTdlL65Ku4S3G7fN/ H6GaAHaLagAdqhBIoy8wXPxixJYtoxugztbMmPYbjHqjPXlK4QdOMUyLIcFeJPyFUrr6DJd4v wMBfE+FiqpCGLr2KUMq3VLjOfCMPlW7HNrCMpgx4wbGutWvhW+4CIR6BrBXfNw/my/izuxCo7 RrN2NP3zgwRxMux2CNRGzTUdVkuiBlURtqaW/L1lxvvZHk2ZAJPQ8O7Zs+9c54bt8qHANDnnq UTf57IcwolDxp1bj7JulnpgzIkj+eIrymwi+ruSH/Xdk8qSIv7zFmSPa4RhuSUHD2vAgBZYW7 LbhZGMvc6KRgtwj9+EghhMtT4vDuuMmZcNHY+vH/luprYveKjQO0KaKBHYptmQ+DknJbZg1ci c4bXWDTOsXbYArgP0iQFZ0YWFMxAJIAmpUsyLVzUkOGcr5lnMZLyE2wSzUhL8HhddC/C45BEL bLi0Fvxa5eY9q0Bf3P7mSyzGijQZnKOOGtuc7hIJ709NaEvJcgT7SLJqyg4tqBMiNrl9o5AK5 yzsEud8gsh01F03ZTrzA== Archived-At: Subject: [core] [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 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 Mar 2021 17:33:48 -0000 Hi, After some discussion, I got convinced to formally submit a draft, explicitly describing a simple lost retransmission detection mechanism to prevent RTO when a retransmission is lost. While full featured stacks can address this issue within the RFC series already by using TCP RACK, on a more constrained platform where only SACK support is viable but not RACK, this mechanism may be an interesting alternative. Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is included, as it may be the case that current implementations which recover from lost retransmissions may not actually use this as a subsequent congestion control signal, and retain the ssthresh / cwnd from the initial loss recovery - and it is certainly debatable, if a single, or two engagements of a CC reaction is in order. The mechansim described is very conservative (another CC reaction, and requires more data to be sent, to have high confidence when retransmitting a prior retransmission). https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 (The graph in the appendix needs some overhaul, as PRR is becoming standard). Best regards, Richard From nobody Fri Mar 12 10:27: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 866943A1A41 for ; Fri, 12 Mar 2021 10:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 uHszHqDWX0wv for ; Fri, 12 Mar 2021 10:27:01 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 EAD263A1A48 for ; Fri, 12 Mar 2021 10:27:00 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id j4so2062038uan.1 for ; Fri, 12 Mar 2021 10:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iBJnp2vm+Ts9Y38eXAtTjNfqCakQUrPprUYehZYdI7I=; b=dDqQ/BkzDxBEZAtEXC8nQHiyT4YB/cOAs4sSHVZeoae1wnIHMZ1jU3yaM33FxcCADE OsA0mCQ1RYp2TuMii2L6CAkhLt/9ScAYB4VjKS+3v5Bf2CGx6+UPRmVRJObOCjfEnYf0 xEHpiLWPXUu/NkZ6zgje4Jw47fUgZV1p0neDzsMkBEd2gruNmfe6y2JGOBG32GCJom1G 2pzxBQWkCDZBFrd3nc4rSB/NA+Q+cqH1KvyqpC4ObFZO6zaJHyq/hAv2/Q+T7g1WNAu+ NlH7ijcb4eP2uBcbKVhgCoBrEXOEfcOMpdMuTbjut9VyNlMk7GjrxTDhzIozbuc7JlYN 2eUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iBJnp2vm+Ts9Y38eXAtTjNfqCakQUrPprUYehZYdI7I=; b=S9niGhoQIUD6D+yaxUCx1e/SI7IfCihtnYqu0Lt6ONZ6Ki9XHzy7CDH+NEmkA22bgM sJ1wjyPzluvdfMGHOEpNs8ug6A/cmbiPtRwZbSIerzqp3ORGD//gjKn9gDHvDajctPt3 1CrNhAwvr18gjjnh3jmfHaTkzqRsXx4hMybYqnWnHjh4eYoNXR0ZrAT/pmWZBfeRonbY 5YUepM8RcQ6+OzEif65qQgQW9Fr990NJDcVSEl3NnTspYVSZp4n2VtjRBAsWiorO07oQ t+LNHojlR9X2UeVWfvUfG8LCj6zCieZd4JOQZL0DSHzjkFrW+f+6bWuMHCus44Ix8hzn e92w== X-Gm-Message-State: AOAM5337xP+l3C5Qu3/xmu2swWT5Zk476xKFjIoL1sHbw7q4q3916H0p aLDq1WJ8HcpY/Ql9ybe3z3xaN8WSPjAFASMPkL0xNw== X-Google-Smtp-Source: ABdhPJz5A4uSnih5eD0mGnbSNZZ1QWJ6qXdH4IgFp9YYO3/xsDl1zTSQ9GufCJM+Zs2A0lODcwcH8O/g83XNU+KSXlY= X-Received: by 2002:ab0:382:: with SMTP id 2mr10114030uau.46.1615573617698; Fri, 12 Mar 2021 10:26:57 -0800 (PST) MIME-Version: 1.0 References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> In-Reply-To: From: Neal Cardwell Date: Fri, 12 Mar 2021 13:26:39 -0500 Message-ID: To: "Scheffenegger, Richard" Cc: iccrg IRTF list , tcpm IETF list , core@ietf.org Content-Type: multipart/alternative; boundary="000000000000980f7c05bd5b0b01" Archived-At: Subject: Re: [core] [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 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 Mar 2021 18:27:03 -0000 --000000000000980f7c05bd5b0b01 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard wrote: > Hi, > > After some discussion, I got convinced to formally submit a draft, > explicitly describing a simple lost retransmission detection mechanism > to prevent RTO when a retransmission is lost. > > While full featured stacks can address this issue within the RFC series > already by using TCP RACK, on a more constrained platform where only > SACK support is viable but not RACK, this mechanism may be an > interesting alternative. > > Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is > included, as it may be the case that current implementations which > recover from lost retransmissions may not actually use this as a > subsequent congestion control signal, and retain the ssthresh / cwnd > from the initial loss recovery - and it is certainly debatable, if > a single, or two engagements of a CC reaction is in order. > > The mechansim described is very conservative (another CC reaction, and > requires more data to be sent, to have high confidence when > retransmitting a prior retransmission). > > https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 > > (The graph in the appendix needs some overhaul, as PRR is becoming > standard). > Thanks for the ID! Indeed this could be a useful algorithm to document for nodes too constrained to run RACK. You mention in the ID that there is a TCP stack that "started using LRD more than two decades ago." Just curious: is that FreeBSD? This approach sounds similar to (a) the improvement in the paper that your informative references cite as [SACKPerf], and similar to (b) the algorithm added in Linux 2.6.24 in 2008 in tcp_mark_lost_retrans() (later removed in the era of RACK). And it seems perhaps (a) and (b) are roughly the same thing, since the [SACKPerf] paper mentions their idea was incorporated into Linux 2.6.24? But I wasn't sure what the relationship is. I did not see [SACKPerf] mentioned in the body of the ID. Would it be possible to add some text in the ID that mentions [SACKPerf] and clarifies the relationship of the ID to the [SACKPerf] paper and Linux code? best regards, neal --000000000000980f7c05bd5b0b01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 12, 2021 at 12:34 PM Sche= ffenegger, Richard <rs.ietf@gmx.at= > wrote:
Hi,<= br>
After some discussion, I got convinced to formally submit a draft,
explicitly describing a simple lost retransmission detection mechanism
to prevent RTO when a retransmission is lost.

While full featured stacks can address this issue within the RFC series
already by using TCP RACK, on a more constrained platform where only
SACK support is viable but not RACK, this mechanism may be an
interesting alternative.

Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is
included, as it may be the case that current implementations which
recover from lost retransmissions may not actually use this as a
subsequent congestion control signal, and retain the ssthresh / cwnd
from the initial loss recovery - and it is certainly debatable, if
a single, or two engagements of a CC reaction is in order.

The mechansim described is very conservative (another CC reaction, and
requires more data to be sent, to have high confidence when
retransmitting a prior retransmission).

https://datatracker.ietf.org/do= c/html/draft-scheffenegger-tcpm-lrd-00

(The graph in the appendix needs some overhaul, as PRR is becoming
standard).

Thanks for the ID!

Indeed this=C2=A0could be a useful=C2=A0algorithm to docume= nt for nodes too constrained to run RACK.

You mention i= n the ID that there is a TCP stack that "started using LRD more than t= wo decades ago." Just curious: is that FreeBSD?

This approach sounds similar= to (a) the improvement in the paper that your informative references cite = as [SACKPerf], and similar to (b) the algorithm added in Linux 2.6.24 in 20= 08 in=C2=A0 tcp_mark_lost_retrans() =C2=A0(later removed in the era of RACK= ). And it seems perhaps (a) and (b) are roughly the same thing, since the= =C2=A0[SACKPerf] paper mentions their idea was incorporated into Linux 2.6.= 24? But I wasn't sure what the relationship is.

I did not see [SACKPerf] ment= ioned in the body of the ID. Would it be possible to add some text in the I= D that mentions [SACKPerf] and clarifies the relationship of the ID to the= =C2=A0[SACKPerf] paper and Linux code?

=
best regards,
neal

--000000000000980f7c05bd5b0b01-- From nobody Fri Mar 12 11:26: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 58D6F3A0121 for ; Fri, 12 Mar 2021 11:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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 UyvVIrSEWqTQ for ; Fri, 12 Mar 2021 11:26:01 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50072.outbound.protection.outlook.com [40.107.5.72]) (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 7DB243A00DB for ; Fri, 12 Mar 2021 11:26:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QAlii9WSpIEMcbJWO1Nj1z220zdD74gNptHKWa+jw4EkTan021VCEnWA5nLnUkCae+M8hb78XLPDrasMWAweGZXPLCCGb+o7PUeO8gl3ZbskvwCUcnpFdAtbO21Z3C043slFnmgDnyBzFb+2sa0lMqgzfzSXSYs1+D+OK4wB730kaOeYRMGsXk7DGmtUT13PuvPKQPshGqC+c/C7EsHcyildYeBSoZnjj9mRGvHvmnAUcYeVwlSCnVg6imK0RV843P0923zLFJ7BSxSfe23K0nS/K6oT3f506lAkwFatOausnKsUPS6KlvHYeyMyVEZbYF48MM0A+zAxaUkBS2PY0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6bQi+J0f0irlq/t7paEWUdwOP9oc2ANWCQ53tXVOJ5Q=; b=gGRVdAgJf7+qbnNXxGlHzvXIznMfXBL30LHkFZ4IZRnlFR6Ed8S21BhlZ+NInOKEbhjGdQbryvxffuhSXDVrkQ9GMpXPcOl1BbcNdCnz7QKf3I57FInFKRlLnfIg+/dHU6riklxiOFwNwK3iwbSStIyMvmConr6TiMgt/a9lwvJtHmR5XEzqEdVI4oNiwKhfgHMduPyOTC3ymMcb/BbyVMKL1BiVqHbvbOLGWfKJEjgRmx/WU0dSYOJmY1DHDTzhzov6Whc5w3hZdJ3j1PRi0VUykwDOfwgsZ++oQPaEdbsdorzPtJ/LpjPxgArqqOIuDhbL89S68hXq7cMU+kK3aQ== 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=6bQi+J0f0irlq/t7paEWUdwOP9oc2ANWCQ53tXVOJ5Q=; b=FlTBbc6fOZM0Fb3NS5sWmddpuq+DDhOaVDe27SN3g2QybkMhQvaNhebz8HjF81iR6nDWUJ+ROsjhfmhxlElvglvvFfri6QbZBHWndxh/gWtS5qoW4NF8JICOSjEan9ql51l2mqbYmg9m6u+uxaJI8UqK61A4/07ROmaVK2TCexg= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB3066.eurprd07.prod.outlook.com (2603:10a6:7:2f::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Fri, 12 Mar 2021 19:25:57 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::2887:d795:feec:2f59]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::2887:d795:feec:2f59%7]) with mapi id 15.20.3955.011; Fri, 12 Mar 2021 19:25:57 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Core WG mailing list Thread-Topic: [core] OSCORE: clarification on protected-response requirement Thread-Index: AQHXFaqXgfykelx8uUWhdctHdO6T4aqA0HuA Date: Fri, 12 Mar 2021 19:25:57 +0000 Message-ID: <18264A65-1D45-4850-B0D8-3663651431A0@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21030800 authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.249.67.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9bc1d75b-560e-4b6e-b659-08d8e58ca98f x-ms-traffictypediagnostic: HE1PR07MB3066: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0yiaAu6GlcV4USCabZyQ8C+o1tTri0QwZlOVcFJP9zLu1jLu/whCiYjh1bnbuQZVK+GgVyd2lWXOd+AwNad/3Edk3+yeW6xdeYAnxnUCEfmUPyPGILaUW8sNCzD4mEEw6UnNSHwgQsD7SQHRkhvNVYEG6gClGvQvRrHkgq/ClkoL2fHGWmB5nR/EXpQx1u8z5qy3Ehwa36Myrj8yHfB49QTCwHqMmApuXGsiXJoNYuVUltEq2R7NkHKNUTmOZrA069zZ4jAdB/eUl7o64Xul3Iy8jJWnWANSZ+oEpdFDLA//UCai7Ucgw+86NFiTscx7Q6EACN0q7DGGWqpIIg/VnWVM1YHLy8rAuie5x5lFkgpCJLqUJModZo97+V8kek7BLvie9tnAh0bMu72RQGmIIcNcBNVkhlhCE2BjC/Brt+Qfkx22RUK/JDpB1nEaX2zRaF4I7P0b2dleWUnLtv0WTiaasS2VRqUjGl6y42J6KLinnf8aFsZLdUBnNMRviMVsnKNMpyJjE0qjM8++jO3ALanXi3nyLlcwHmy4rPgtJdoo1vO1i/mLkeVMgEiN0+qoCgnFh09Am7rkAUPOTdQhW9xa0/nu80QbgNEmCyrWDYdBZoJsl2hR0vvykhXfUvnw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(39860400002)(376002)(366004)(8676002)(6486002)(5660300002)(2906002)(66556008)(6506007)(71200400001)(8936002)(478600001)(316002)(6512007)(110136005)(186003)(26005)(2616005)(66446008)(83380400001)(33656002)(36756003)(85202003)(85182001)(86362001)(76116006)(66476007)(66946007)(66574015)(64756008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TXhFZjJFQk83ZzBNSmpHVjAwYWR3dWJ2MnF6SWp0U21tNFNKM05RTTByY3I5?= =?utf-8?B?Wi9vYkJlaWxEV2FDQlR4QlZmRG5Cd2hBcTBoUHBLb1RjWUlqUkFwc25EczVK?= =?utf-8?B?NmhWcEZtWUVLZnRvQWtNR1dKUkRkb0JCMGc5ekxiVFNwdWQ0NEQrakVhdjlI?= =?utf-8?B?bVdwenVLQzY2QjZvc29ib1o0NjJqY0hHT3V1eXpsZXVoc0ZPT3I0blU3RUJs?= =?utf-8?B?U25yVmcvNEsrVUIzejArT29WdHNNKzZqRUVYNDhtZWlZd2ZvQ2VPd3pURzFL?= =?utf-8?B?SlRyZm5iOExvaGFTZXAreXRTaldWNHc2dlBkbThhMnNFSGE0ZXYwdW1ZaE1F?= =?utf-8?B?V2c2Wmc3aXVybjB4c2ExLzRSZHl3K3JZaVRHYkRzZkZTcFUyY2hwNVdncklC?= =?utf-8?B?RExEc1dMakNObzBud3J0clN2MlhBUjhWTWR1U0FDeEhYR3hDRjVwTUZmUUNa?= =?utf-8?B?QXJlOVVhUVFraWNGY2tNdmgxM0lsM082YmZkekppdWdSTlJWRmdFOEI1azRa?= =?utf-8?B?a2ZWYjJOcUgrT1RZSkJxRlV5L0NXSVFlQ3hqa1llbzhvVjFoL3FaamtpdHZX?= =?utf-8?B?K0k1UTUxeHIzRFBmZkVvWFZJZFMweDZ2SEE1UGFydUpIYndWYSsvWkNDeXVH?= =?utf-8?B?L0h1USs5QTdxMjFnU0dBM3ZYdjUxbm5LVjVpVEVHZVpQdVVZVnhLRDJtNFFB?= =?utf-8?B?bUtROGcrQWRORkVjMUhxTmo2RVZmTjI0ZHNJazZtcTlGeHROa2w1R1pmelkv?= =?utf-8?B?YkNOaDlnVkQyQkZIbWU1VGFXR3FoVFBDRyt6Q21DKzl1aDlZQzBUb1k0R2x3?= =?utf-8?B?aUN4b0VyOUJBVmxVQnIvZkg3SFlKc3lXZS9idS85WGYyMkx2bG1GNjVzT00x?= =?utf-8?B?QWJoZHRNL3MvRlNJYkowRXAxVmk1Y29qakVuVFhPM2RBdWtuOVpVWTVINE5w?= =?utf-8?B?RkYzNE5RMDBobEJUMkgxQTJ3Rk1Tc3Q2a3M5bU9VOHdCZ1FPbm05QVFsUEhZ?= =?utf-8?B?ZFR1OTY4STU4RlBjR1ZUeXorSnp3VTUwRm9ucWFxMVQ3VDljb1ppeVBCT3I1?= =?utf-8?B?bnlpZEt2MHVnMnpYRGxmRGxSL2ZSNm1PWU9aS2I4d1M3QlhFa2hyZ2wwR1Bn?= =?utf-8?B?ZkFIOXk2bXBQaTk4eVJKd2ZTcitqWmZUdHZISWdnVXBIdk82ZEdtL0hLaE0r?= =?utf-8?B?QXRTNG4wbXBSeUNYL2x5bHZETnlCNm9jbjdDTWpISEVCdmY2SzFpRHZIdjQv?= =?utf-8?B?eVI5eDhlRWJsMXJRbWc3d3ZMMXp6cVc5am5pSk1KblFxMXQxTm81VjlHMEJK?= =?utf-8?B?bTU0U3VEZFhCaEc0TkFCbG9zQW1LU0JxM3dsajJyTGMxY1FpV0FHdWdYQmx5?= =?utf-8?B?K3Y0UkI2T05wZlp6N1dkSnBTZmt6WW1aRHdXNlFTN1J2QWtIRXUvSDhVTEZi?= =?utf-8?B?ZXYrQ25VQVZMdEwxL08yV21ncXVlUFpYelJrdTVGQzYzRjJjRisrVFJZVjdR?= =?utf-8?B?TCtjU3gzNHA5WlhGeDhKSTJZN1JhMVc1Q29TZHVuL0hSUW1kbW4rR2hDNmNL?= =?utf-8?B?dVd3RG0wWmJtSU5VL1lOVm9qcDZJWnQwTHg1d2pOdTNKWHJ0N1VyOW5Ra2s0?= =?utf-8?B?SnVESmU5YlF5S2tuUXdUMS80czVZRTlRWmxSTVFCcmxqM1JJNnNDSWhTNkts?= =?utf-8?B?NDNudE93UDdSTVEwV1lNQmpONkZmcVJJS3MwMzl5UUhrWnFtVFlSWW0xeFJY?= =?utf-8?Q?/p3wEduBT98Uf4Y6bfI3NmeRjttGhRh+5t5qDdj?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <408FA4120D142A41BD1C4D9169FBCB65@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9bc1d75b-560e-4b6e-b659-08d8e58ca98f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2021 19:25:57.4695 (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: 2VCLcArxbYMvvMksfM8Sz7xPg9RHVDfNOSwn2Kbx7/79i16JyEo9O9/N1hogie0H7tMti6/iTa5AfTg9K4roVPH9Tf8Oz5iKjzsqxuvrqvI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3066 Archived-At: Subject: Re: [core] OSCORE: clarification on protected-response requirement 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 Mar 2021 19:26:03 -0000 SGkgQ2hyaXN0aWFuLA0KDQpBcyBmYXIgYXMgSSByZWNhbGwsIHRoaXMgc2VudGVuY2UgaW50ZW5k cyB0byBzYXkgdGhhdCBpZiBhbiBPU0NPUkUgcmVxdWVzdCBpcyBzdWNjZXNzZnVsbHkgcHJvY2Vz c2VkIGluIHRoZSBzZXJ2ZXIgYnkgT1NDT1JFLCB0aGVuIHRoZSByZXNwb25zZSBTSEFMTCBiZSBw cm90ZWN0ZWQgd2l0aCBPU0NPUkUgaS5lLiBoYXZlIGFuIE9TQ09SRSBvcHRpb24uIFNvIGluZGVl ZCwgdGhpcyBjb3JyZXNwb25kcyB0byB0aGUgY2FzZSB3aGVuIHRoZSByZXF1ZXN0ICJpcyBzdWJq ZWN0IHRvIE9TQ09SRSBwcm9jZXNzaW5nIiwgd2hpY2ggaXMgdGhlIG9ubHkgY2FzZSBjb25zaWRl cmVkIGluIHRoZSBkcmFmdC4gRXJyb3JzIGR1cmluZyBDb0FQIHByb2Nlc3Npbmcgd2lsbCBiZSBw cm90ZWN0ZWQgIGJ5IE9TQ09SRSB3aGVyZWFzIHRoZSBlcnJvcnMgZHVyaW5nIE9TQ09SRSBwcm9j ZXNzaW5nIGFyZSB1bnByb3RlY3RlZC4gDQoNCkFzIHlvdSBwb2ludCBvdXQsIGluIGRyYWZ0LXBh bG9tYmluaS1jb3JlLW9zY29yZS1lZGhvYywgaXQgaXMgc3BlY2lmaWVkIGhvdyBhbiBPU0NPUkUg cmVxdWVzdCBjb250YWluaW5nIEVESE9DIG1lc3NhZ2VfMyBpcyBwcmVwcm9jZXNzZWQgYnkgRURI T0MuIFNvIHRoZSBxdWVzdGlvbiBpcyBob3cgYW4gZXJyb3IgaW4gRURIT0MgcHJvY2Vzc2luZyBp cyByZWZsZWN0ZWQgaW4gdGhlIENvQVAgcmVzcG9uc2UuIENsZWFybHkgdGhlcmUgY2FuJ3QgYmUg YW4gT1NDT1JFIG9wdGlvbiBpbiB0aGUgcmVzcG9uc2Ugc2luY2UgdGhlIHJlcXVlc3QgZGlkIG5v dCBzdWNjZXNzZnVsbHkgY29tcGxldGUgdGhlIE9TQ09SRSBwcm9jZXNzaW5nIC0gaXQgZGlkbid0 IGV2ZW4gc3RhcnQuIElmIEkgdW5kZXJzdGFuZCByaWdodCwgeW91ciBxdWVzdGlvbiBpcyB3aGF0 IGlzIHRoZSByZXN0cmljdGlvbiBvbiBDb0FQIHN0YXR1cyBjb2RlcyBpbiBjYXNlcyBsaWtlIHRo aXMuDQoNClRoaXMgZ29lcyBiZXlvbmQgd2hhdCB3YXMgY29uc2lkZXJlZCBpbiBSRkMgODYxMy4g QWx0aG91Z2ggdGhlIHNlbnRlbmNlIHNlZW1zIHRvIGZvcmJpZCB0aGUgdXNlIG9mIHN1Y2Nlc3Mg Y29kZSBpbiB0aGlzIGNhc2UsIHdpdGggdGhlIGludGVycHJldGF0aW9uIGFzIGFib3ZlIHRoZSBz ZW50ZW5jZSBkb2VzIG5vdCBhY3R1YWxseSBzYXkgYW55dGhpbmcgYWJvdXQgdGhpcyBjYXNlLCBz aW5jZSB0aGUgY29uZGl0aW9uIG9mIHRoZSAiaWYiIGlzIG5vdCBmdWxmaWxsZWQuIA0KDQpZb3Vy IHByb3Bvc2FsIHRvIGV4dGVuZCB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgY3VycmVudCB0ZXh0 IHRvIG5ldyBzaXR1YXRpb25zIG1ha2VzIHNlbnNlIHRvIG1lLiBJIGRvbid0IGtub3cgaWYgdGhp cyBuZWVkcyBhbiBlcnJhdHVtLCBidXQgSSB0aGluayB0aGF0IHdlIGF0IGxlYXN0IHNob3VsZCBk b2N1bWVudCB0aGlzIGludGVycHJldGF0aW9uIHdoZW5ldmVyIGl0IGlzIHJlbGV2YW50Lg0KDQpJ IGhvcGUgSSBhbnN3ZXJlZCB0aGUgcXVlc3Rpb24uDQoNCkfDtnJhbg0KDQoNCu+7v09uIDIwMjEt MDMtMTAsIDEzOjQwLCAiY29yZSBvbiBiZWhhbGYgb2YgQ2hyaXN0aWFuIEFtc8O8c3MiIDxjb3Jl LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4gd3Jv dGU6DQoNCiAgICBIZWxsbyBhbGwsDQoNCiAgICBPU0NPUkUgY29udGFpbnMgdGhpcyBzZW50ZW5j ZToNCg0KICAgICAgIEEgc3VjY2Vzc2Z1bCByZXNwb25zZSB0byBhIHJlcXVlc3Qgd2l0aCB0aGUg T1NDT1JFIG9wdGlvbiBTSEFMTA0KICAgICAgIGNvbnRhaW4gdGhlIE9TQ09SRSBvcHRpb24uICBX aGV0aGVyIGVycm9yIHJlc3BvbnNlcyBjb250YWluIHRoZQ0KICAgICAgIE9TQ09SRSBvcHRpb24g ZGVwZW5kcyBvbiB0aGUgZXJyb3IgdHlwZSAoc2VlIFNlY3Rpb24gOCkuDQoNCiAgICBJIGFzayBm b3IgY2xhcmlmaWNhdGlvbiBvbiB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzIHN0YXRlbWVudC4g SSB0aGluaw0KICAgIGl0IGlzIHJlYXNvbmFibGUgdG8gY2xhcmlmeSB0aGlzICh3aGV0aGVyIHRo YXQncyBpbiBhbiBlcnJhdHVtLCBhIHBpZWNlDQogICAgb2YgQ29SRSBsb3JlIG9yIGNvcnItY2xh cnIgSSBkb24ndCBrbm93KToNCg0KICAgICAgIFRoaXMgaXMgcmVxdWlyZW1lbnQgYXBwbGllcyB0 byByZXNwb25kZXJzIGluIHdoaWNoIHRoZSByZXF1ZXN0DQogICAgICAgYWN0dWFsbHkgYmVjb21l cyBzdWJqZWN0IHRvIE9TQ09SRSBwcm9jZXNzaW5nLg0KDQogICAgVGhpcyBjbGFyaWZpY2F0aW9u IGlzIHJlbGV2YW50IHdoZW5ldmVyIHRoZXJlIGFyZSBvcHRpb25zIG9yIG1lY2hhbmlzbXMNCiAg ICB0aGF0IG9jY3VyIGJlZm9yZSBPU0NPUkUgcHJvY2Vzc2luZyBhbmQgZXhwbGljaXRseSBzdGF0 ZSB0aGF0IHRoZXkgY2FuDQogICAgdGFrZSBlZmZlY3QgZXZlbiBpZiB0aGVyZSBhcmUgcGFydGlj dWxhciBvdGhlciBvcHRpb25zOyB0aGUgcHJvdG90eXBpY2FsDQogICAgZXhhbXBsZSBpcyBjb3Jl LW9zY29yZS1lZGhvYy4NCg0KICAgIFByb3RvY29scyBidWlsdCBhcm91bmQgc3VjaCBvcHRpb25z IGFyZSwgaWYgdGhlIFJGQzg2MTMgc3RhdGVtZW50IGlzDQogICAgaW50ZXJwcmV0ZWQgc3RyaWN0 bHksIGxpbWl0ZWQgdG8gbm9uLXN1Y2Nlc3NmdWwgcmVzcG9uc2VzLiBGb3IgZGlmZmVyZW50DQog ICAgcmVhc29ucyAoIkRvbid0IGFidXNlIHByb3RvY29sIGVycm9ycyBmb3IgYXBwbGljYXRpb24g ZXJyb3JzIiwgY2FjaGluZywNCiAgICBtYXliZSBvdGhlcnMpIGl0IG1ha2VzIHNlbnNlIHRvIGFs bG93IHN1Y2Nlc3NmdWwgY29kZXMgaW4gcmVzcG9uc2VzIHRvbywNCiAgICBhbmQgdGhpcyBpcyB3 aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlzIGFib3V0LiBGb3IgZXhhbXBsZSwgaWYgaW4gRURIT0MN CiAgICB0aGUgcHJlZmVyZW5jZSBzaG91bGQgYmVjb21lIHRvIHJlc3BvbmQgc3VjY2Vzc2Z1bCB3 aXRoIGFuDQogICAgYXBwbGljYXRpb24vZWRob2MgbWVzc2FnZSAoZXZlbiBpZiBpbnNpZGUgdGhh dCB0aGVyZSBpcyBhbiBlcnJvciksIHRoZQ0KICAgIHJlc3BvbnNlIHRvIGEgcmVxdWVzdA0KDQog ICAgICAgIFBPU1QgRURIT0M6IE0zIE9TQ09SRTouLi4gZW5jcnlwdGVkIHsgR0VUIC9mb28gfQ0K DQogICAgY291bGQgYmUNCg0KICAgICAgICAyLjA0IENoYW5nZWQgQ29udGVudC1Gb3JtYXQ6IGFw cGxpY2F0aW9uL2VkaG9jIHsgZXJyb3ItY29kZSwgLi4uIH0NCg0KICAgIHdoaWNoIGlzIHVuZGVy c3Rvb2QgYXMgYSByZXNwb25zZSB0byB0aGUgRURIT0Mgb3B0aW9uIHBhcnQgZHVlIHRvIGl0cw0K ICAgIGNyaXRpY2FsaXR5LCBhbmQgZm9yIHRoZSBzYW1lIHJlYXNvbiB1bmRlcnN0b29kIHRvIGhh dmUgaWdub3JlZCB0aGUNCiAgICBPU0NPUkUgb3B0aW9uIChhcyBwcm9jZXNzaW5nIGRpZG4ndCBn ZXQgdGhhdCBmYXIgYW55d2F5KS4NCg0KICAgIEkgdGhpbmsgdGhpcyBhbHNvIGJlIHJlbGV2YW50 IGZvciBhbnkgY2FzZXMgb2YgYXBwbGljYXRpb24tbGF5ZXINCiAgICByZWRpcmVjdGlvbiAoZ2l2 ZW4gd2UgZG9uJ3Qgd2FudCB0byBtaW50IDMueHggY29kZXMgZm9yIHRoYXQpIGFuZA0KICAgIHBy b3RvY29sIG5lZ290aWF0aW9uIChub3RoaW5nIGZsZXNoZWQgb3V0IHlldCwgYnV0IGtub3dpbmcg dGhlDQogICAgYm91bmRhcmllcyB3aWxsIGVhc2UgZXhwbG9yYXRpb24pLg0KDQogICAgQlINCiAg ICBDaHJpc3RpYW4NCg0KICAgIC0tIA0KICAgIFRvIHVzZSByYXcgcG93ZXIgaXMgdG8gbWFrZSB5 b3Vyc2VsZiBpbmZpbml0ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlciBwb3dlcnMuDQogICAgICAt LSBCZW5lIEdlc3Nlcml0IGF4aW9tDQoNCg== From nobody Fri Mar 12 12:39: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 436BA3A1263; Fri, 12 Mar 2021 12:39:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 qnkORzpACx2K; Fri, 12 Mar 2021 12:39:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 D7F653A1261; Fri, 12 Mar 2021 12:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615581567; bh=49uhzMNA+YOE3shfKcRSdLRuzm1LfutfQJ6PSXdVUIA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=hrogQD8Fv3g26xGqEuj9RiSN1U8bn69zzxxP7v4KbJGAxHWm+iJJY5Ie1+RCoplro tnWYa2pocpHx/b1Oasom5AfSfRd8u5m6bqG5epzBRjkFMMTpehjq5xldjaS3NDuRk8 DiRuXa6bZR9TYyMtLMKApoWCDsMXrBYCvj6UpKR8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.199] ([178.115.129.107]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M42jQ-1lKoZC3EWW-0008Mv; Fri, 12 Mar 2021 21:39:27 +0100 To: Neal Cardwell Cc: iccrg IRTF list , tcpm IETF list , core@ietf.org, lwig@ietf.org References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> From: "Scheffenegger, Richard" Message-ID: <5ecbb7fd-556b-2233-b35b-baec71a28b58@gmx.at> Date: Fri, 12 Mar 2021 21:39:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:uRiC8Nk8xq1rgE8l8THaPJ6wAd6lR7G9zmQfnm5NRTTcxlyoU+y SHg7tAUbArAyw0VWqfXm9V8+n1aLKhMbuWA5xvRGKlYkVRDcto5VN17W178vOd0vW+Pfc5t wY3iBtYlo5mjH7N20ChPWwG8klYCt7PAxLF1TAMGqknZ+WnmSQ8utfAKXT9iXyWy2WZXkHn 1xoqYgShL+tGTdC4r0GNA== X-UI-Out-Filterresults: notjunk:1;V03:K0:W88di4rZv4I=:Au37d+75dwA9Gt7GXhSYlu hj0vzic8QR4KW2wQcV5netKm85OgUJH8gTt7sfJbvtLBi2azevVUOWUxczxft6MhwOcXnyWLi 0u9BxYTuf0WJb6WOztkFgFtJlUkH6C5XgIdueaaY/1+SxhZ/Q77a7jv/eIKmBma1yDJwAZ1bo R9c8xdSrsM8LxCmOx5mBDFmaDjBYGP2BuWe3FowWwkKASOu+u08kUmPfmWOLI6vOOVFXAqkc7 GdOXptPd4qimQYPeDZpkPSmL8n3CJ2uXLKGxCN7dybzos4q0clhCVjcLo7CCtBXZD5oJpwPIw w3JccyVKlS0VUEfTW62l+92fLz8Vz6bvgGs1Cbqb85vcImvVjIsvW4AEaNFqeO2qUqP625ohe k6asE6pJ/EtqBA9FJWHaWuHoZaQ9CYYs9cXlmTc7rvlOxwgeiwK2DND+8WY96fIK0IzlmPg6i 5LyAoz10Ert7MkvToTLfIzPum1806ZK6++/OxFjxwYIsAkh19ua9w9QUhRw02GS2XRpndJkLK q6cyq5+U5ulp6D01RoyXPTUC7XppHuCrjWFjA4Cg6tEZ15ZhXecctIOeT6EiBIYJAOgIH1r/m EHSsv9mSBbCZbrtrs8kCM1Sm8VxFLHwxb8J+pO/SUnTtMnZAIrvscbqsQ4VJyhDFnoA41hHnq I3VtDmSPXmI4p57E5Oz/N7rRxiiwZ32BOsyK3T1/E3S1yiCZn/9qsiWi33pEjbCpdOSVchQSp aQmHy4RIgDdO25lP4P7mqKptc7nqERW8BOc0d5Xs5El2cFoPXDaVb/pHQ5o4CMKjHVyxi68RA mKYjer2DMkvnEG2eNlzqHckntDldGLDFs3wUu4/MGu5dewgASE9AOcLw7TXusD6HH5Qv4Q7+v 8hIN81NVPUHTeUjk8Ckw== Archived-At: Subject: Re: [core] [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 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 Mar 2021 20:39:33 -0000 Hi Neal, I was specifically thinking about Linux, but my recollection as to when it first showed up there must have been skewed. The SACKPerf reference appears to be dead (only a copy on archive.org is available - I don't know if that is valid to quote instead of the link that I found all these years ago. https://web.archive.org/web/20150103014718/http://projects.itri.aist.go.jp= /gnet/sack-bug.html In any case, the improvement described therein sounds as if some more limited form of lost retransmission detection was already present in Linux before that. (For single Hole/SACK Ranges). As I am not that intricately familiar with Linux, is my assesment correct that (at the time of ~2.6.24), CC would not be triggered anew when a lost retransmission is detected? If you have a suggestion for an appropriate text honoring all the prior work on Linux, I would be very grateful. I would also like to invite you to coauthor this document, if you want to help refine the text further. Also, I have a more aggressive mechanism, using a heuristic to differentiate between a SACK for an original segment vs. a SACK for a retransmitted segment, and using the latter to also engage LRD. As this variant does not rely on new data to be sent, it can also work at the end-of-stream, albeit with some potential misdetections of lost retransmissions (again superceded by TLP / RACK). However, I felt that the conservative mechanism is the proper starting point for now. Best regards, Richard Am 12.03.2021 um 19:26 schrieb Neal Cardwell: > > > On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard > wrote: > > Hi, > > After some discussion, I got convinced to formally submit a draft, > explicitly describing a simple lost retransmission detection mechani= sm > to prevent RTO when a retransmission is lost. > > While full featured stacks can address this issue within the RFC ser= ies > already by using TCP RACK, on a more constrained platform where only > SACK support is viable but not RACK, this mechanism may be an > interesting alternative. > > Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is > included, as it may be the case that current implementations which > recover from lost retransmissions may not actually use this as a > subsequent congestion control signal, and retain the ssthresh / cwnd > from the initial loss recovery - and it is certainly debatable, if > a single, or two engagements of a CC reaction is in order. > > The mechansim described is very conservative (another CC reaction, a= nd > requires more data to be sent, to have high confidence when > retransmitting a prior retransmission). > > https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-0= 0 > > (The graph in the appendix needs some overhaul, as PRR is becoming > standard). > > > Thanks for the ID! > > Indeed this=C2=A0could be a useful=C2=A0algorithm to document for nodes = too > constrained to run RACK. > > You mention in the ID that there is a TCP stack that "started using LRD > more than two decades ago." Just curious: is that FreeBSD? > > This approach sounds similar to (a) the improvement in the paper that > your informative references cite as [SACKPerf], and similar to (b) the > algorithm added in Linux 2.6.24 in 2008 in=C2=A0 tcp_mark_lost_retrans() > =C2=A0(later removed in the era of RACK). And it seems perhaps (a) and = (b) > are roughly the same thing, since the=C2=A0[SACKPerf] paper mentions the= ir > idea was incorporated into Linux 2.6.24? But I wasn't sure what the > relationship is. > > I did not see [SACKPerf] mentioned in the body of the ID. Would it be > possible to add some text in the ID that mentions [SACKPerf] and > clarifies the relationship of the ID to the=C2=A0[SACKPerf] paper and Li= nux code? > > best regards, > neal > From nobody Fri Mar 12 12:49: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 4CDF33A12D2 for ; Fri, 12 Mar 2021 12:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 71y8xZHFLW42 for ; Fri, 12 Mar 2021 12:49:55 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 54D843A12CC for ; Fri, 12 Mar 2021 12:49:55 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id w76so13175813vsw.10 for ; Fri, 12 Mar 2021 12:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BYUZdwHKQq50SSHjx1INnk337CXEvne0SYTTjsvhqcs=; b=KU4R8LImdks1BP0l3/UQfHeMw8cszFt8i8GQXuOD1UpAc5qV61kQJOWJDlvarL8bKn bnernxC6j6GFvyWcvM+KWZWq8Eby+XqJqg7D4E1oAe5zMcKv0sZZIUUmcGQ1qvpSJ1S4 MXRhF1zbdSL9Ow8cLu4cNB25AzsoEk7gdz53f+X8aWFth++BTJsznT1yG9d7+ssDGKiM xDdJA9c1SNR1e0spSuiM9nydSfVaYNsO1CkEfROi/Y/ltMrsWg8BFNex8YeD9LyE0XV/ vcOq3oRLSS/HPBHr3TRGJCeue3TFIUioJsUjVvDHc2yrdO32e29MGTtiT7p65Wlevfy2 Tx1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BYUZdwHKQq50SSHjx1INnk337CXEvne0SYTTjsvhqcs=; b=V14hexyGW6FxpcSgGzSAz1E9CDhpEEnRpz7pcPLH8yiFfnp47p7PSjsYxDhnMywRr6 k0d7bABoqjc9U5RoYLS67S7HzzXyOVTu4wJZuXikbCwPXh1vS05eg//6uSEs3F7qKZYy +OyWcmPOdzFwBYh2ph5jR/g1MlaPOQ5ErBbMjneKM3x58Gu2Ace/YEOzaw9UMDm8OHxJ KwAxXkknkhC1QZQaEGnCbzWBfcFzD3umlk+aTw5t+3VXTdudUje/TThqEEhm2+qKBLVO WVBc2GLLB6o91lEOVZci8YRiv2FO2/MFOOK2/XY3HxKkI0Q6LMWxVryxrlGojgh/tFSL 47VQ== X-Gm-Message-State: AOAM532R2+rnkGycaKRE3kHCqQlh7tnZDrTTdhRxRhgAjRnoj9aY2CQK wsZHJdj6Q2TkYrV8uIhU/IP1r/3++nK3bTUjSxSIiA== X-Google-Smtp-Source: ABdhPJxZCDuHgcqQg/8ec0Cb8yUD+qrmibeK5he5iAxIkQznor0ftuTXP0B0hwQCfkCqxeHFZZ4GSqXNhbrf0vw/1iI= X-Received: by 2002:a67:1005:: with SMTP id 5mr160546vsq.52.1615582193423; Fri, 12 Mar 2021 12:49:53 -0800 (PST) MIME-Version: 1.0 References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> <5ecbb7fd-556b-2233-b35b-baec71a28b58@gmx.at> In-Reply-To: <5ecbb7fd-556b-2233-b35b-baec71a28b58@gmx.at> From: Neal Cardwell Date: Fri, 12 Mar 2021 15:49:36 -0500 Message-ID: To: "Scheffenegger, Richard" Cc: iccrg IRTF list , tcpm IETF list , core@ietf.org, lwig@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 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 Mar 2021 20:49:57 -0000 On Fri, Mar 12, 2021 at 3:39 PM Scheffenegger, Richard wrote: > > Hi Neal, > > I was specifically thinking about Linux, but my recollection as to when > it first showed up there must have been skewed. > > The SACKPerf reference appears to be dead (only a copy on archive.org is > available - I don't know if that is valid to quote instead of the link > that I found all these years ago. > > https://web.archive.org/web/20150103014718/http://projects.itri.aist.go.jp/gnet/sack-bug.html FWIW looks like there is a copy of the [SACKPerf] paper here: http://www.hep.man.ac.uk/g/GDARN-IT/pfldnet2008/paper/kodama_y%20Final.pdf > In any case, the improvement described therein sounds as if some more > limited form of lost retransmission detection was already present in > Linux before that. (For single Hole/SACK Ranges). Oh, interesting. Maybe so. I have not had time to read the paper or the preceding code. > As I am not that intricately familiar with Linux, is my assesment > correct that (at the time of ~2.6.24), CC would not be triggered anew > when a lost retransmission is detected? Yes, that sounds correct. In Linux Reno/CUBIC/etc there would only be one cwnd reduction until SND.UNA reaches the value SND.NXT had at the time of the previous reduction. That is, there is one cwnd reduction per "window", where "window" is interpreted in sequence space rather than time. > If you have a suggestion for an appropriate text honoring all the prior > work on Linux, I would be very grateful. I would also like to invite you > to coauthor this document, if you want to help refine the text further. I have not had the time to read the [SACKPerf] paper that seems key to this archeology, so would defer to your wording. Thanks for your generous offer, but my plate is a bit full at the moment. > Also, I have a more aggressive mechanism, using a heuristic to > differentiate between a SACK for an original segment vs. a SACK for a > retransmitted segment, and using the latter to also engage LRD. As this > variant does not rely on new data to be sent, it can also work at the > end-of-stream, albeit with some potential misdetections of lost > retransmissions (again superceded by TLP / RACK). > > However, I felt that the conservative mechanism is the proper starting > point for now. Sounds interesting. I would agree that documenting something close to the existing LRD algorithm that has a lot of air miles from 2008 until RACK seems like a good place to start. best regards, neal > Best regards, > Richard > > > > Am 12.03.2021 um 19:26 schrieb Neal Cardwell: > > > > > > On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard > > wrote: > > > > Hi, > > > > After some discussion, I got convinced to formally submit a draft, > > explicitly describing a simple lost retransmission detection mechanism > > to prevent RTO when a retransmission is lost. > > > > While full featured stacks can address this issue within the RFC series > > already by using TCP RACK, on a more constrained platform where only > > SACK support is viable but not RACK, this mechanism may be an > > interesting alternative. > > > > Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is > > included, as it may be the case that current implementations which > > recover from lost retransmissions may not actually use this as a > > subsequent congestion control signal, and retain the ssthresh / cwnd > > from the initial loss recovery - and it is certainly debatable, if > > a single, or two engagements of a CC reaction is in order. > > > > The mechansim described is very conservative (another CC reaction, and > > requires more data to be sent, to have high confidence when > > retransmitting a prior retransmission). > > > > https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 > > > > (The graph in the appendix needs some overhaul, as PRR is becoming > > standard). > > > > > > Thanks for the ID! > > > > Indeed this could be a useful algorithm to document for nodes too > > constrained to run RACK. > > > > You mention in the ID that there is a TCP stack that "started using LRD > > more than two decades ago." Just curious: is that FreeBSD? > > > > This approach sounds similar to (a) the improvement in the paper that > > your informative references cite as [SACKPerf], and similar to (b) the > > algorithm added in Linux 2.6.24 in 2008 in tcp_mark_lost_retrans() > > (later removed in the era of RACK). And it seems perhaps (a) and (b) > > are roughly the same thing, since the [SACKPerf] paper mentions their > > idea was incorporated into Linux 2.6.24? But I wasn't sure what the > > relationship is. > > > > I did not see [SACKPerf] mentioned in the body of the ID. Would it be > > possible to add some text in the ID that mentions [SACKPerf] and > > clarifies the relationship of the ID to the [SACKPerf] paper and Linux code? > > > > best regards, > > neal > > From nobody Fri Mar 12 14:25: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 4FBAD3A169A for ; Fri, 12 Mar 2021 14:25:44 -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 irjdL1kMTQiV for ; Fri, 12 Mar 2021 14:25:41 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80084.outbound.protection.outlook.com [40.107.8.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67E23A168F for ; Fri, 12 Mar 2021 14:25:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aWFHR91lw4WidbANC3TlsEXnqjOyGnrvMCWw50XIPd9MCMa9eQ1q6Fh5EBo3wUowGaO4vJfYJ2WAU1RAUTvdS41Q9s3iF+XaEG7EkOFpV/NkMmlxvOWLvhBEvixl8S2zEzLrg+5uefnvaXq36EwuijgsQ62VZKQvkQ/LWjVIGHi+nHtb+ydMsy7Ny4pSxAQTjUj7E/iSxZS6OxS3gclQOkCEpOPTrz40A2jREoHl3CjbitJ3H/9Nmtqqs7rfwOcTmibk5DSSxw6mvcq1ybc7WnLrnvEitRZF0uQvbKPv4NEOCuMKxjhQCiRLFoL09REYTeD3UvyV93WbvRfuhz+wug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gxix040gzwK4xrdvh7hhstxB3kPy/NU0UPmQEsoLHbk=; b=h38uFAjILEiRnKY+bQuNLXgPQfhWrPC+70Pqs7UtKMQq4mvujgxbV4SF5BcNyoqhc+jzoBlgMXGgy/C1MNWBmrs1XbA+RqRrVFr+lTGj/guok4iZKmnrIBqa/ErA8quUQw+mH2fwYj+hZnPZyz9G7Ud45J2RSzdnKRAwR35Rye9lIs0t4azNdxUdd1GandFCAC5GRz6Tua58eBTjhVvJnDDIphbgmdgATgS2PydmvxdSPyF6G8QZtPs989U4GHA52CRj+AelVancjjdxc4nq7AcFJFflsmEAAAqiFatWs07ZCb6jfq06l+S3cQO7tlWLhg69gIy23aNKilM9mEkuWQ== 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=Gxix040gzwK4xrdvh7hhstxB3kPy/NU0UPmQEsoLHbk=; b=LZbOyjE8jcJMbt7r4+RmqfOBzvxVGVpt7LMPHfR6RTe8womsaRBibqGXYW3cgbet2osRTjOvwMtCkTHSJp2HdDdvQZZk5Jo2tdGtBtXp5hHOwQxAOT4MJqFLb1EixceMq2e2v1ymQDsHZYX4LJPK01F6iwN4elm6tklsJ3H1Wv0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1016.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Fri, 12 Mar 2021 22:25:37 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3933.031; Fri, 12 Mar 2021 22:25:37 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Fri, 12 Mar 2021 23:25:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MIEcLZ5Dm8f6MwMtpbMgwecCfm7yjQVEA" X-Originating-IP: [92.34.17.243] X-ClientProxiedBy: BL1PR13CA0340.namprd13.prod.outlook.com (2603:10b6:208:2c6::15) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.68] (92.34.17.243) by BL1PR13CA0340.namprd13.prod.outlook.com (2603:10b6:208:2c6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11 via Frontend Transport; Fri, 12 Mar 2021 22:25:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0ad29e1d-49d9-44a5-39a4-08d8e5a5c2ba X-MS-TrafficTypeDiagnostic: DB8P189MB1016: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4941; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: R15o4OmGE4AI+xHGQD3CdeRpd8dWUR2Gtbb1oVvfmJQbwxNEaiqyUezTfByBSu/AqXhctfcGABZKj5IK211NnQSBZEdmiNVclrd7XedJ1yIBPFLN3+3Wc4IYLUvBVMqovOzDkI5HtcYRiEUria+kZ2HKdTP5iOHjBgyFF5EMgspVHma2kdXhp7XbrOwamFueo4GijMjp1VUuw5PbbRVv379zJy1+HXdrGNEmfpxFMYBipj3za0HPD3PAz6cAgVMSB8ow1VJ1cucbJ+cltiv/dZsDlyV23bNWSOBxv8b4d4Pb+9YVyqimP0yXE2VnwlfMCx6f8xDFzvS4djf89eK0dk7BYPqniyMVX9N7UNnyoe2BBuETrhHKT5CO+XSZm48fwiSX6WwkUvCiXwfUpS1kVI0nFRcKPfrMzjilGqjSebVwWuJM4mWQAfYkY1r0iR6U7o9SrEgq5xKpThJOxePUORYeL2Rs8KZydtAChbpKnEIwGV9V+Tcr8MRVrS8cBf0pSl3zSGGQBoroqFw3POrzxLTJjdfdbzlNQexlsodeu7rAF8Nv8M1ZhUiZDb3BewR127r42LSTx3cSxkbTeD2q0EDoR0dZBMHuGDRbdn7GB0RG61L7yRq4gC3ek0dMC2FPk+KKXsKTl3sGgvAAj+EReYYBbWR0AVXm9tovnpxWylliS4hPKJ8yMSMFE/7Dv5ZIjhlRmKdDwFBUgzDa4ub9uVotlTb6FiXe+K1XSI3YKu8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39840400004)(44832011)(2906002)(6916009)(36756003)(8936002)(2616005)(8676002)(86362001)(83380400001)(186003)(66946007)(235185007)(66476007)(31696002)(66556008)(316002)(16526019)(6486002)(31686004)(33964004)(966005)(478600001)(21480400003)(956004)(5660300002)(26005)(52116002)(16576012)(6666004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?S01JVDRtUzJtSFlUTlNNdTlHYzNoNWhiZjBBQjI1d3RHNUx4aHU0bGxnN1g1?= =?utf-8?B?ZkpUUnBOMDJVcmR4N1NRNlhkNVZZYi9vRHhSMVZtSUhrK1VOYmV3bTFwWWx0?= =?utf-8?B?czZOdWNxNnFxa2NFM2oyOFFmMlV0djE1TXRMR0dxTy90WGE1NFBBdXZpdmtw?= =?utf-8?B?cGpWem9zZW9kdEJtTEtrc1RueU5GTWlNOGZsSDNPYjVvdlB2bXhYbjNFSUEr?= =?utf-8?B?c1IvR3lzRG0rT1Y3MC9kYVRPRGpOeGVudkdjUko0U2lvK0dmQnV4ZzlmVEhH?= =?utf-8?B?VXVQcDJWQTgrcDBZQW93VUVoMlZFbUVvZVpTUHI2cnNPbmRiWnR0ZFMzcVhO?= =?utf-8?B?ZFF4ZXUrQUVsYVUrZ1p3bnFBaUlpdGw1QVg3Umw3UGMwTnoxTjVuTXBBNW15?= =?utf-8?B?bXp4V2s5UndMSUNVY0hwNDNXclFDeXVvVlZhY2toOGpsMmFVU0VXcTQyOXdU?= =?utf-8?B?RmdJZ0JRakZyeFhxTFZ5dWp5MVgyYXZlQ3V3UWdLdjVnSWxQak51TEJMWlAw?= =?utf-8?B?cURPTDNDSThZNUU0Zkl4NHBwZitrTnBwb0tZNTNlNFNZdXJvQjE5S09ZOUda?= =?utf-8?B?Y0NUKzNTVnZiUUYvYXVLTnJBSTN3cHNNNDBMYk9ranFOYjl2UFdCS0Vqdlk0?= =?utf-8?B?SkRpd2FtMlJGTHgzTjJQYmtYYUxoOG9weGlhaWp6YS9ORnA1S1M4V1Q2Tk10?= =?utf-8?B?WVI5aC9IK0ZxcXVEbjRNSkdKSys2eHNTR1Z3dVV2eEpRWDhiUlNFVWt4WmVF?= =?utf-8?B?YXdjd29PL3JKaGVmbkwrQVJta2RJV3hhcEFhbERxRmxRNnNtdEN3WlFUWFEv?= =?utf-8?B?WHZaZVVMOG5mL3J1b1hyQi9HZzZVdWFwbVYyY3oydXV3TnB2dUloZ29BWS9L?= =?utf-8?B?SEJQOVQxQm9UaGRNaFpJb0FlWTVpLys5SDErK0E4WmRtUFVPdU9KbmtiL2hq?= =?utf-8?B?UWpabUlGZmQ3V1FnOU9CcDhhVlFjNUJCMlJtNGdPem0vYi9LQXZGa1ZBL3lI?= =?utf-8?B?ZTNNVWg2SmQ1RG1DWHN4dGQwdGFTd3lFZnYzaE8xc0VtMG9zZ3pPeUo2WXBV?= =?utf-8?B?RWk2K0JtMG8raUlVTjY1UGk0ais1QUdVdlk2TU40ZkpLdmpYcnZWUS9sS0ox?= =?utf-8?B?Q2hqOXFEVVg2bTVuaHNZcnlqK0NwbThhUGNpUGFGNkhhWGczdzZYdjhNQmpL?= =?utf-8?B?ODJrVVFGMVhlNzBTZE9EVllrZEhjVzRxMWVZSG1YQnlxRW8wazJTM1lnVjdW?= =?utf-8?B?WTFSUTdFY2dQQ2dhVDFVRitRNzExelFydnZrSGNwa1NzZG9iSDJ1VTQ4aTZI?= =?utf-8?B?R0MxYkRGQUtwaTE2U1lldjRiNks0NC9Xb2h5VTVqRlAzemptMURvbW8zVUdi?= =?utf-8?B?clRWSzkwTmJyZzA4ampZMCtCT3g2YlBTVXA5SHQyT3BYSWVhdW1xUjZncTcx?= =?utf-8?B?T0tGQ2NVNlc1bjkxS3pFWVRQc0pYYm1aN2JZQzVSTVpvYXJmZkM2V2RkWnF2?= =?utf-8?B?RldBSWE1VHRkQ0RoUUVQV09STFRuaXZIOFZYVVo0aW02a3Nnb0tTY1dDMkR5?= =?utf-8?B?N2JnN1dhYlFaTmZyV1lMUjA5VTR4ZnNkWklPQVF2NjFYRkpDRDQzK2R0N1hN?= =?utf-8?B?bXpZN2M2T1l1ckRGS2hvVVVBZndVeUlwZVZvSlg4YU03bGNKbXN2MEFlMlVQ?= =?utf-8?B?ZlI4eUxGcmp6b2h5MXRaN21YRjZLQnZMM01WdStIQ2VQVW1KZDExL1ZGMGQ3?= =?utf-8?Q?hD4ewqb0IeiDS7O7WRkOemcgD7KSxrZWRa3ygR1?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 0ad29e1d-49d9-44a5-39a4-08d8e5a5c2ba X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2021 22:25:37.5161 (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: 1aFf3q9trV+xgwYZ4yKZenLZWktKxobWdCGuaPmiqQlpzxiexHlTaOMhwcdxHreGBkw44QCEzP9bNjKyI0oBjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1016 Archived-At: Subject: [core] WG Last Call on draft-ietf-core-senml-versions 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 Mar 2021 22:25:44 -0000 --MIEcLZ5Dm8f6MwMtpbMgwecCfm7yjQVEA Content-Type: multipart/mixed; boundary="7aIisKmYPW6ubHkLkkmoEq4gwfbHBql8S"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] WG Last Call on draft-ietf-core-senml-versions --7aIisKmYPW6ubHkLkkmoEq4gwfbHBql8S Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, As mentioned during the Friday CoRE meeting, this mail starts a Working=20 Group Last Call on: https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-versions-02 The latest revision incorporates recent review comments from Jaime, and=20 there are no open or known issues. This WGLC will end on Friday, 26th of March. Best, Marco and Jaime --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --7aIisKmYPW6ubHkLkkmoEq4gwfbHBql8S-- --MIEcLZ5Dm8f6MwMtpbMgwecCfm7yjQVEA Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmBL6lsFAwAAAAAACgkQ7iZktA5Y2kNb EAf/XP0MnNERlJFILSnp5dy0QLvuRgqLsnPJr9CIYvRyYVG9nf4r9CF0m/y2J1x/n4w/ObBznaPO KJBsgvwBFEW1CgLLzGOvWh8FcfwJ7U3ZtZFl5MM3VjbQNIWvleIg2mJfiT0NDYug7uaHdvH9mO+8 76ExmXLO+k4IMGAA/yEHcJ+oNJIIC6Z/R03kmPdrHPB+I0NcVUh3/OBskBfR7AExnhUkDl3sTn/Y YzHkNhSJUb+UN72ruOUzLl+A4nIOhGlgDugsCUSSDiI/XjBOtnlMNlOZj9BDSzSsNvKwzoUxymZ/ NZvM+1th53eFOj17tEqbLVzEUWEhVIEqrYbLpiQa7g== =3fvC -----END PGP SIGNATURE----- --MIEcLZ5Dm8f6MwMtpbMgwecCfm7yjQVEA-- From nobody Fri Mar 12 23:35:26 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6343A1042; Fri, 12 Mar 2021 23:35:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161562092502.19554.13289549839348074049@ietfa.amsl.com> Date: Fri, 12 Mar 2021 23:35:25 -0800 Archived-At: Subject: [core] The CORE WG has placed draft-palombini-core-oscore-edhoc in state "Call For Adoption By WG Issued" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 07:35:25 -0000 The CORE WG has placed draft-palombini-core-oscore-edhoc in state Call For Adoption By WG Issued (entered by Carsten Bormann) The document is available at https://datatracker.ietf.org/doc/draft-palombini-core-oscore-edhoc/ Comment: In-room consensus for adoption at IETF 110 being confirmed on mailing list until March 22. From nobody Fri Mar 12 23:38:29 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 599FC3A104B; Fri, 12 Mar 2021 23:38:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161562110835.4622.11062618686857638706@ietfa.amsl.com> Date: Fri, 12 Mar 2021 23:38:28 -0800 Archived-At: Subject: [core] The CORE WG has placed draft-tiloca-core-observe-multicast-notifications in state "Call For Adoption By WG Issued" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 07:38:28 -0000 The CORE WG has placed draft-tiloca-core-observe-multicast-notifications in state Call For Adoption By WG Issued (entered by Carsten Bormann) The document is available at https://datatracker.ietf.org/doc/draft-tiloca-core-observe-multicast-notifications/ Comment: In-room consensus for adoption at IETF 110 being confirmed on mailing list until March 22. From nobody Sat Mar 13 10:47: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 3A1643A1444 for ; Sat, 13 Mar 2021 10:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCnOB7_8llwF for ; Sat, 13 Mar 2021 10:47:42 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) (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 2FF143A1440 for ; Sat, 13 Mar 2021 10:47:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CgwKUez6vegobW1ByvQZJ+RwE5B4nchVQcVwa7ypzdVRP+YfgD7pTfc0Yc+/EJAQOgiQIeMaIKB6K6/BfjmlWBM/zjFGE291sWT70qvhiNgNhQCEVA1idco4DsHv1WXhmzkWT1MQrX0vIidjJ5V35qlWulseb0Cv/wjmaSl0vOq5AGtMNwk/pnh9A5Du6L5WXt4sfD8/2M6l5Q7580WiaRjnALDMZyzspnJy/+F05KINzTPQqgf34/KO90E0IFJqSAx6muN6edRwXaeB4qKK7LwCcTscNceFwFgvJR4VFB2bLDdZm6el9Q1GKGfezOD+dnUI5bqDuVs2KAX8XhyerA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HHTtOIcw4TVOsTdoz2sw32+sdnLcJgvag2gT3Y+2POo=; b=nDWBjqi1j2KX38z46QCKuYe2TYUBa+e1KdJCj9GcPOEIA7tiLiuAJfu7wttaPmN94YY6QpgG0v5MO3TJl305bTbqoxqW+kgzyD+fKprRzeB4ZSmGExfDpHMnJe4N5DnVmRIMV+bnC6PhmazAoP8Y3TbkMeqxRGhY0ouyQyzutwPS2uu0WAZGU90tBKsiy172/Fs5Zk/BnHO1YEkgiggQSTHR4kt07ZUXaB5syosuHVc21IpSH5fXOX8M5q+/reTUOpE3liXxlvUX43tyX+wJ9i5yxDuI1vfT4x0Y3YCH3b0GtBW21ydsSZ0zc1+P+BQwY89HhQKjtPdEzQb80rrh+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HHTtOIcw4TVOsTdoz2sw32+sdnLcJgvag2gT3Y+2POo=; b=BKsPBn4ODFDr/FaFI5uGzqflUwjypu0CsfHGuherbV7G0xU78yKwfAYBXOVChrD1v7PcWQ4jylxSh4NrpmGaZg6LCSc9MetXuXQBHlYyALlbEPqYfWoID/EsNQ7aQ1k5PV4pbWQrUNBMlqJD7FbEFKxSo4oA/rHVUMNu3zsZly4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1596.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Sat, 13 Mar 2021 18:47:37 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3933.031; Sat, 13 Mar 2021 18:47:37 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <63c6b5e8-21bf-bed4-53f1-b3885a138464@ri.se> Date: Sat, 13 Mar 2021 19:47:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ltiLYQwnTXjIeq4MOJeb3okMz3dx20mV0" X-Originating-IP: [45.83.91.164] X-ClientProxiedBy: HE1PR07CA0026.eurprd07.prod.outlook.com (2603:10a6:7:66::12) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.3] (45.83.91.164) by HE1PR07CA0026.eurprd07.prod.outlook.com (2603:10a6:7:66::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11 via Frontend Transport; Sat, 13 Mar 2021 18:47:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6d4afe70-9e87-4f8f-dc6b-08d8e650790c X-MS-TrafficTypeDiagnostic: DB9P189MB1596: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JhlUx1zo+hEhbzRFbEwnwd7D7dcgjwytW+78qP8G71WbN0m4vcNYriZ0Orko3FFLLyCI67nk4PawNfdQXqUQPRt5aNPn4q7gDJgDWb87shPQUpG5oFIIE7wqovsuDd2L48Zx3x8ZpZzAjxyLDYsScJmz3W/hCZzdAWSdLZ4EFIQkURK6vcf9Gxcf56yu900zXNgfIwAZqCkkzQDxodFSKl2OYsG3IO0Qai28jerAafYApc8ZtXDUGEkLaSuOop/qgmpf+/RqPouf8tm8g+UmkeC1onCAtYm2O2BPyEhWrciZGBPAAZqA4LbgVkhEgNMnctNxW+lR/S8xQsuw8AkwJmW7JKsm478PEqZNB5h+fslRDvOaqQROzBB4mRyXlCj/0/LhoePsDAiXqiIpTN4/S0AhAfAMSHGSMesSGbMtx15sH7AJEqQSdXVHbWGzFO9pfXH79NkArtQLu8pZLxz42SqCGSaXl0X294e05o3LiSaxUYjGGhYlBiX/XDQNgcJ9fVEtVQl01w/l/E8k7fTowWM1XDPXodIR06dADBjpN/FtcEvcnJT8wi1/etN0wUX+dwSMz7UxSrJU9e265rBCos+EsXI2ZeKnnXBWp4+eUeoNoXutQKvnwMF18/Rcvcw9uJzYSGr98faXcCYAi01hdSXgS2Jh0RGoBwoQczxta7Dh8SmnAugaorCcKrfk4AOzheRcsoBzDSHFZwqVwmhKNAwhUKIzAlA2ojau359ugG8= 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)(39840400004)(396003)(136003)(366004)(376002)(346002)(83730400007)(30864003)(6486002)(235185007)(478600001)(83380400001)(66616009)(66574015)(66556008)(6916009)(5660300002)(31696002)(36756003)(66946007)(86362001)(16576012)(26005)(2616005)(186003)(44832011)(16526019)(21480400003)(956004)(8676002)(966005)(316002)(2906002)(31686004)(8936002)(33964004)(66476007)(52116002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ejZwQm1xUnp3d2t0REhkZDhFUGZsVjhIWWJ0U1YzSWh2U1pxYTYvRVRJSUN4?= =?utf-8?B?dWVFTmZxQXJCY3R1ZGUzRnlmMXFycDRzZ0RCaENkZHMzdVR2d1lYSGN4OGcw?= =?utf-8?B?UkFheGJrL2pwVTllR2d4Q2ZROUxiTkZNelZGaDNtSUNiMm9BWVozU1pCazBQ?= =?utf-8?B?ZEdoS2IyTkx4cnJuZFBacFFOUVpySG14V05JZDI5T1QraExVeWt4aG5naXA5?= =?utf-8?B?R0FkYUd3dll2TFpkWnFYZ3ZTTnR0V1ZRdVpaM1ZncXo1Z2QzTzFvVU9aQ2FO?= =?utf-8?B?UWZLbng5NklGUFlsZFNja3RaL2Z0MXByQk9waGZtUGw0ZXpWVDgvaWZSMVlZ?= =?utf-8?B?T3hLenF4OWRlUUlZV2tBQ2NoWmQ0VlFqS05yNXREcTZ1dkl3Vk5MejRCMWVn?= =?utf-8?B?YVNPV0pqNmlUTERjQVhxNWJHWm9uU1h4ZU9SWi9UV21FdFBCV1pVeVJXdHZu?= =?utf-8?B?MkxTRnZ4d1N6a1hxS2JNOVg5NmZyVE5WTXY3VnZmcUYyMDc1MHQxOElpOXox?= =?utf-8?B?OGZYRkhQM1ljT1B1bmhzVHBpWmdKRTd3OVVjbWxFQXlhSndnWWdzUUVqRlNN?= =?utf-8?B?TElxTlZMUUtIZTlxWE8wUjlvNEFib2dycExucmZJaWNielZ6UHRMVDRtUEpv?= =?utf-8?B?ZnBkYitLTEJyY055ZCtGNlJUT0tDdStOdng4WVpGdG9pUkdjenVZTktSVEtX?= =?utf-8?B?eGZyQTA4ZU1KVDFmSU1xWG5sREtmTzlWbzVUNlZsOEtFUk1IS2NuT1hSemRB?= =?utf-8?B?UzhxcG5xZlNhQTZwZnhNTzdkK3JFUk1Hb2tPQ0tLU0tMTkJvUnNKRzBlVG1i?= =?utf-8?B?QmtkaWMrN3lXUkkyc2FhNGhOUnF2cUhTbGhock9qVzNsU2JGR1NYOUlKMUtE?= =?utf-8?B?L1l0K3RiZm5kUGV1T2ZOZGNyMGE3eTN1MVZ3WUZrMTNIdXhOb3NUMjViMkEy?= =?utf-8?B?N0s1UFRmVUFyc3dHLytwdDJ3OE8xNkF3aXNCT2lUZkgxaHE1TGprTGhZcDFQ?= =?utf-8?B?bDhNeGpBYi9MNXRKbEgrdlRML3p6ZXBCV1dKakw3R24vMkc1bTB5YU13ZjhU?= =?utf-8?B?TllVWmlrK0gwcXFUNStlZllndUsrSXIreEVoRU1FeVZqbElQUHArVExvYmE3?= =?utf-8?B?L3VDTmFKaGVTMCtqTFQ2S2tIOC9ndFNydGt3eFZMWHYxYzA1NjFSWmhoeDF0?= =?utf-8?B?eFBLNmVBenhQNlpOdFB4aTQ0b1dtdTFHeVNXano5aUh2QUhDd1I3ZHVJcGZU?= =?utf-8?B?WXYza3ErVi9HR1NaQzY2dEs0NTRJaVVhazdjalJadVp0WURCd0ltTGVkbFls?= =?utf-8?B?ZjZPTDdxWFM1cm9HQ2ZnU1oyNmN4Y00zWEQwWUNXU0R2T0Jzb1FsL0FqVERv?= =?utf-8?B?cThpeUtwT3Q2TitCcEFVc2huWjVhcW8xNUpkVkZVdVYzWG9MNTB4N3BQemRB?= =?utf-8?B?WWRTcE10eDBtN0FGWkYzOGE0ajRCVkhxQ0pjeXl4Vmg5Q2JzRktoQnZVVmVw?= =?utf-8?B?dERpeExsTEdZeGlqREpCSWxNRExEMzRCM0h1ZDJnSlMyRi93cm0zZzJzQU41?= =?utf-8?B?ODhuWUNrdm1RWkRwbUFjTFlkcGU1NERVY3ZtRUIzNEx2MjAzdEcwVUpQRlF4?= =?utf-8?B?VDRiVEU2SkR4eENScm4zeFcxRExMaWpWaE5wOHVLR1V4bEs5VkJvdElPalh5?= =?utf-8?B?aVZ6TTNuOC9PRExmVzRuaTN1SHE4aTZyR1F1bTRsSkcxT1NPb1NIOE4rMFNx?= =?utf-8?Q?N0LLXKZ5GfSvcIhBg0yGCpnm4So4vTO8gSQiO3u?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 6d4afe70-9e87-4f8f-dc6b-08d8e650790c X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2021 18:47:37.7534 (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: gycScLm7qVHsvmgL0HWaK9gv0KdEsIwgffsvg3wpem3JWiRahZ4Z5G/DXOyxmq7+xZZJuiu044QNCeh8AOl9IA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1596 Archived-At: Subject: [core] CoRE @ IETF 110 - Minutes and summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 18:47:47 -0000 --ltiLYQwnTXjIeq4MOJeb3okMz3dx20mV0 Content-Type: multipart/mixed; boundary="THz910kZ5d4SxHjFbQbEnlhxhnmxfkUCn"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <63c6b5e8-21bf-bed4-53f1-b3885a138464@ri.se> Subject: [core] CoRE @ IETF 110 - Minutes and summary --THz910kZ5d4SxHjFbQbEnlhxhnmxfkUCn Content-Type: multipart/mixed; boundary="------------7715A392E2E503796FA3AEC8" Content-Language: en-US This is a multi-part message in MIME format. --------------7715A392E2E503796FA3AEC8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, The minutes for the two CoRE sessions are available at [1]. Thanks a lot = to the note takers Michael Richardson, G=C3=B6ran Selander and Rikard H=C3= =B6glund! Please, send possible fixes and updates to core-chairs@ietf.org or to=20 the mailing list, preferably within the next 7 days. The recordings of the two CoRE sessions are available at [2][3]. Finally, you can find below the usual summary of the two sessions, with=20 fewer technical details. This summary is also available at [4]. Thank you all for your participation and contribution! Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/110/session/core [2] https://www.youtube.com/watch?v=3DGteEGOyW5JI [3] https://www.youtube.com/watch?v=3DVKhUnOji8XA [4]=20 https://github.com/core-wg/wg-materials/blob/master/ietf110/core-110-summ= ary.md ---------- # Summary ## WG and document status Carsten Bormann standing in as chair for Jaime during IETF 110. Thanks to Barry Leiba as outgoing AD, welcome to Francesca Palombini as=20 new AD. * Published =C2=A0=C2=A0=C2=A0 * RFC 8974 (was draft-ietf-core-stateless) * RFC Editor Queue =C2=A0=C2=A0=C2=A0 * draft-ietf-core-dev-urn-11 * IESG Processing: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-resource-directory-28: Approved-Ann= ouncement Sent =C2=A0=C2=A0=C2=A0 * draft-ietf-core-echo-request-tag-12: Approved-Annou= ncement to be=20 Sent::Revised ID Needed * In Last Call =C2=A0=C2=A0=C2=A0 * draft-ietf-core-yang-cbor-15:=C2=A0 In Last Call, u= ntil 2021-03-17 =C2=A0=C2=A0=C2=A0 * draft-ietf-core-sid-15:=C2=A0 In Last Call, until 2= 021-03-17 * In Post-WGLC processing: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-yang-library-03: waiting for shephe= rd write-up =C2=A0=C2=A0=C2=A0 * draft-ietf-core-comi-11: waiting for shepherd write= -up =C2=A0=C2=A0=C2=A0 * draft-ietf-core-oscore-groupcomm-11: processed WGLC= comments and=20 one more review; ongoing work on open points =C2=A0=C2=A0=C2=A0 * draft-ietf-core-senml-data-ct-03: processed WGLC co= mments; synch=20 with draft-bormann-core-media-content-type-format =C2=A0=C2=A0=C2=A0 * draft-ietf-core-new-block-07: processed WGLC commen= ts ## Groupcomm-bis * draft-ietf-core-groupcomm-bis-03 Latest updates include: support for reverse proxies; caching of=20 responses, with two types of cache entries at the proxy; a response=20 validation model between client and servers with a new Multi-ETag=20 option, and between client and proxy with a new Group-ETag option.=20 Cacheability with end-to-end security is still possible using the=20 deterministic requests of draft-amsuess-core-cachable-oscore. It is preferable to move the new part on response validation to a=20 different document, e.g. draft-tiloca-core-groupcomm-proxy. Next steps=20 are about addressing open Github issues; moving some content to the=20 rights places / different documents; implements aspects involving e.g.=20 observe and blockwise. ## Group OSCORE * draft-ietf-core-oscore-groupcomm-11 Latest updates addressed points raised at IETF 110 and from Christian's=20 review at https://mailarchive.ietf.org/arch/msg/core/pXEyxhbf-s2wgGDzrDhUNPsHZZc/ Two main open points remain. 1. Admit the recycling of Group IDs, as currently forbidden to avoid=20 problems with long-living observations. This can rely on the Group=20 Manager storing for each group member the GID used in the group when=20 that member joined, and adapting group rekeying processes accordingly.=20 No objection to this update. 2. Related to Github issues #72 and #73, on using the same identity key=20 for both signing and Diffie-Hellman key derivation for the pairwise=20 mode. Not really a common practice, need to be proven secure. Point=20 originally raised by Ben Kaduk https://mailarchive.ietf.org/arch/msg/core/ujj_I-LlqW9fq__quh-YqKS0fF0/ =C2=A0=C2=A0 There's a pre-print in progress, to prove that the approach= is=20 secure, possibly after minor changes to the exact key derivation steps.=20 A less preferable alternative is to have storage and provisioning of=20 separate signing and Diffie-Hellman keys. More on this point in the next = months. Plan for v -12 is to address the two open points above. That should be a = stable version, there are no other known issues. ## OSCORE Group Discovery * draft-tiloca-core-oscore-discovery-08 This method uses the Resource Directory to discover links to an OSCORE=20 group manager, hence to discover OSCORE groups and how to join them. The = latest updates include information on the pairwise mode of Group OSCORE; = consider also the signature verifier as possible client; revise the=20 examples. Marco's implementation has been tested against Christian's RD, covering=20 all the steps defined in the draft. https://bitbucket.org/marco-tiloca-sics/ace-java/src/master/src/test/java= /se/sics/ace/interopGroupOSCORE/CoAPEndpointToResourceDirectory.java coap://rd.coap.amsuess.com The next version will have more security considerations and will align=20 with latest additions to the RD document. Plan to integrate the=20 individually implemented steps into the actual joining node and Group=20 Manager. The document needs reviews. ## Multicast Notifications * draft-tiloca-core-observe-multicast-notifications-05 This method enables a server to send multicast notifications to a group=20 of clients. Possible to also use Group OSCORE. The server sends a=20 phantom observation request to itself; observe notifications are=20 responses to that request. This version has a new encoding for informative error responses to the=20 clients; a new encoding for expressing addressing information in the=20 informative responses; optimization for a server self-managing its=20 OSCORE group and for having the phantom request as a deterministic=20 request (see=20 https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/).=20 Next steps include considering also reverse proxies and deterministic=20 requests used together with proxies. All main components are already in=20 place. In-room consensus for adoption: +13 in favor, no objections. To be=20 confirmed on the mailing list. Will review: Esko, G=C3=B6ran Planned implementations: Christian, Marco ## Groupcomm proxy * draft-tiloca-core-groupcomm-proxy-03 =C2=A0=C2=A0 - Discuss updates and open points The document describes a signaling protocol with two new CoAP options,=20 to enable proxies in group communication. This last version has especially revised the encoding of server's=20 addressing information conveyed in one of the options; and has added=20 also support for reverse proxies (with two examples). Appendix A defines "OSCORE in OSCORE" as useful here for the proxy=20 authenticating the client before forwarding, but it is actually=20 forbidden by RFC 8613. Now we have use cases for it, but it would=20 require proper definition, analysis and update of RFC 8613. Support to move out "OSCORE in OSCORE" and have it in a separate=20 dedicated document. Possible collision of identifiers would be possible=20 to address leveraging differences in transport information. Next steps are about addressing raised points raised and covering the=20 case where client and cross-proxy talk HTTP. Earlier promised reviews: Christian and Carsten. ## Cacheable OSCORE * draft-amsuess-core-cachable-oscore-01 This method enables caching of OSCORE-protected responses; all group=20 members can act as a deterministic client with a well-known Sender ID=20 and Sender Key. The exact encryption key is derived for each different=20 request. The key derivation process is similar to the one in the=20 pairwise mode of Group OSCORE. One trades some security properties with=20 enabling cacheability. This also improves the way things work in=20 https://datatracker.ietf.org/doc/draft-tiloca-core-observe-multicast-noti= fications/ During the hackathon, Marco and Christian interoped and decrypted each=20 others' deterministic requests. Finding from the hackathon improved some = design aspects, already in the editor's copy. Next steps are more interop, process the feedback and then go for a=20 proper review with security in mind. ## OSCORE with EDHOC * draft-palombini-core-oscore-edhoc-02 This method combines the last EDHOC message to establish an OSCORE=20 security context together with the first CoAP request protected with=20 that OSCORE context. The last version has determined one specific approach based on a new=20 EDHOC option with zero-length; and added an optimization, i.e. only part = of the EDHOC message goes on the wire, while the rest can be=20 reconstructed by the server, saving at least 2-4 bytes. Next will be to keep this in synch with the main EDHOC document; some=20 specific point can better fit in this document. In-room consensus for adoption: +9 in favor, one "not raise hand" (not=20 against, but not sure either), no objection. To be confirmed on the=20 mailing list. ## AEAD limits in OSCORE * draft-hoeglund-core-oscore-key-limits-00 This considers the AEAD cipher limits defined in=20 https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/ , and=20 defines additional actions for OSCORE. Need to count key usages and=20 renew the OSCORE context of the two peers when a limit is passed. One=20 limit 'q' is about performed encryptions with a key, while 'v' is about=20 failed decryptions using a key. Plan to cover more algorithms than CCM_8 = and give optimizations for constrained devices and implementation=20 guidelines. * https://mailarchive.ietf.org/arch/msg/core/h5JHgX5wTBkJtrKl_ezswiCdUBI/= The above is important to happen in OSCORE. Renewing the security=20 context might also be useful to do for other reasons like for=20 counteracting key compromise, especially if the rekeying provides=20 perfect forward secrecy. The original procedure used to compute the limit considers arbitrary=20 assumptions that yield the actual limits now considered in the draft.=20 It's also unfair to some particular algorithms. It would be good to have = an overall revision of that procedure. OSCORE in particular may consider = more appropriate values. The possible revision of the procedure belongs to somewhere else; the=20 document above can still recommend better values to use, with some short = explanations. ## CORECONF Comi * draft-ietf-core-comi-11 The CORECONF documents core-sid and core-yang-cbor are in last call. Got = comments for core-sid on the intentional creation of a new global naming = system; good to get views from the security community. For core-comi issues came up during the shepherd write-up preparation:=20 from netmod on incompatibility between uint8 and int8; string that may=20 not be URL-safe; definition of "CBOR key"; key vs. CBORencode(key). Also = required for minor clarifications when using blockwise transfers and=20 pagination, and about leading zeros in base64 encoding of SID numbers. A revised version is needed as addressing these points. Changes to the=20 above encoding should not be an issue for implementations. Then to be checked if a new Working Group Last Call is needed. ## SenML Versions * draft-ietf-core-senml-versions-02 This version addresses comments from Jaime (e.g. approach to bitmapping=20 a number). Ari added to his SenML validator the bit for additional=20 units. Ready to move on. We will start a Working Group last call. ## SenML Data CT * draft-ietf-core-senml-data-ct-03 This version provides editorial clarifications and decompression bomb=20 security consideration. Still having a normative reference to=20 draft-bormann-core-media-content-type-format (MCTF), which seems to=20 require some time to become an adopted document, based on the Monday=20 discussion in DISPATCH. Proposed to remove MCTF as normative reference, and include into=20 senml-data-ct only the minimal set of things needed from MCTF. This seems good and straightforward, but better to first wait for more=20 discussion in DISPATCH before deciding. The two documents can anyway=20 separately proceed in parallel. Next step is to have a a Pull Request on the senml-data-ct document to=20 gain time and be ready to take the new direction. ## New Block * draft-ietf-core-new-block-07 Addressed WGLC comments and further follow-up comments from Christian.=20 Other than technical refinements, this version provides better=20 clarifications on being specific for the DOTS use case. Available implementation based on libcoap, to which a PR has been=20 submitted. Has been tested in DOTS environment and behaving as expected. Reviewers largely happy with the current version. This can be seminal=20 material for a possible blockwise-bis. The document will move forward; Marco will be shepherd and start the=20 shepherd review and write-up soon. ## Dynlink * draft-ietf-core-dynlink-13 This version incorporates latest feedback also based on discussion at=20 the latest interim. The Conditional Attributes have been separated into Conditional=20 Notification Attributes and Conditional Control Attributes. New=20 attributes "edge" and "con" have also been added. Required harmonization for the use of the attributes "band" and "con",=20 having in mind the use that LwM2M does of the defined parameters. http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/= HTML-Version/OMA-TS-LightweightM2M_Core-V1_2-20201110-A.html#Table-512-2-= lessNOTIFICATIONgreater-class-Attributes The first part, about the parameters, is pretty mature now. The second=20 part on the dynamic link concept needs more discussion and work. The two = parts are independent. Agreement in the group to split the current document into two different=20 documents about the two different parts above. The dynlink document will = be the one focused on the link material. Work is needed also on covering a case with proxies, looking at=20 interactions as end-to-end or hop-by-hop. So far the hop-by-hop approach = has been privileged. In either case, the impact of possibly present=20 proxies has to be considered. ## RD extensions and protocol negotiations * draft-amsuess-core-resource-directory-extensions-05 * draft-amsuess-core-transport-indication-00 The first document defines RD extensions as to what you can do with the=20 RD without changing the spec. This includes the reverse proxy extension, = for asking the RD to provide a publicly reachable name and act as a=20 reverse proxy. Often used (also during the IETF 110 hackathon); most of=20 LWM2M uses a similar mechanism. The RD may also partially partner with a = proxy. The undesirable side effect is URI aliasing, which can be avoided if=20 devices use the RD only as proxy. Similar problem in protocol=20 negotiation case, coap+tcp:// and coap:// both collapse to a same resourc= e. To avoid that, the second document suggests an approach for proxy=20 discovery. A server announces that it has a proxy at a location, by=20 using link-relations. Everything hosted on this host is reachable via a=20 specific proxy. No URI aliasing in the application (possibly only on the = wire). Next steps are to gather feedback, tuning relations, and update the RD=20 extensions to show how it can be used. Some security considerations can=20 be further elaborated by building on some from the HTTP working group. ## A Data-centric Deployment Option for CoAP * draft-gundogan-core-icncoap-00 This draws parallels between ICN and CoAP deployments, already shared=20 with the ICN community. ICN allows not specifying a server endpoint, but = rather focuses on content delivery, using name-based stateful forwarding = and content caching. Possible to use object security end-to-end protection (also to cached=20 content); all hops on the path creates state, which is consumed when a=20 response traverses back. This can also prevent traffic amplification=20 (DDOS). Caching is hop-wise, so retransmission can originate from any=20 intermediate entity in the path, which reduces link traversals. Tried already with OSCORE, using cacheable OSCORE, see=20 https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/. It = worked quite good, with improvement of success rates in lossy network. A related paper from 2020 considers a CoAP deployment similar to an ICN=20 deployment using only standard CoAP features. Most ICN systems support multiparty communication (mostly using request=20 aggregation and response fan-out, or request fan-out and response=20 deduplication). Ongoing work to provide more results with multi-party=20 communication. Future work to allow dynamic proxy discovery. The=20 Resource Directory can help to discover links and as announcement point=20 for routes (especially to a particular good next-hop proxy). This is an unconventional way of deploying CoAP but worth exploring in=20 CoRE; it's not out of scope. It can also be discussed in T2TRG. Since firmware update is a good use case, also the SUIT Working Group=20 can be interested. This approach allows to retrieve an update from the=20 closest location, rather than always from a certain update server. For the multi-party case, there are building blocks for this too as work = in progress in CoRE. --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------7715A392E2E503796FA3AEC8 Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Za= RDP C4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt0G4Ck= Unq 5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6= NHf EWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QO= XrX MGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpb= G9j YSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLB= BYC AwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JNWDTX6h1MUsgejwj4R= Xs6 UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s86ncVygiDUh9fbSDTcuzOp2qgu9nsc= 8sE sYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4M= xMh mi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0K= nXl AczWxCD3J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZs= zJe TvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZkt= A5Y 2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFboHwJaeKZ6s3dCGpzDlV6bLrRM= 9LN /sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4LK4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgS= E/F 26QK2VL9Y/ur5BHgUI34mUar4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgi= YgG QeDvlisWb9NtsxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxz= s6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFCzwWDB4Yfg= AAK CRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod5Njc1jlXqItPKDXzvmTJA= Cy7 JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF9tNL38mzm8emh5vV3XDy8arElEP7bE9Jf= gm2 3Lm9OEwubbtjLYf0z7poncThsYUuaEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+l= alf GS+9OSv9nJD9mdoTNk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXAC= iGG 0zpK666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVSnWWQF= v/9 2zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As1S6e/OC5Mdo5jQhe0= Ozj u5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgtdoCsRRQQxWME8+V95FqsleNd1QfEU= /jM +HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG= 8x2 rFxUOQ7B2DqmxBrRX3GLokNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ= 84o zNX5q52bRceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUCV= I16 cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggAhFyfi+VlqgIj5= a54 npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35HBXZvuFGn5DHBUYhqBFWTx+H5= zHg GBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47OyDDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+= BF9 wtDs6M6YAs9GdHIDhvUJWGDhOZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmt= JXP +QtZRfSaabFxCVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1v= gai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFufWd/D/9PO= 2eZ HdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1Uxu3gbtJoQ4PbT9rJan4Oe= m7/ NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDzALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6= gEq /+3+KROA0ZKEDWcE2rVEzw4UEv37BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5Z= kaS LN6kFoZPZFhrf0fhlLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4= G4D vUAYt5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13YYlqw= g9A yIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw9EpnqLWkWgm5KbT+J= 9h/ tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPzCf3do08MiLWTRVcrY6pXVTGAF/c41= uC6 520+RFm4ytAfrefNac1+5eZBG5k84sTdV9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKX= XPF djMJtVRWSZ/gzaBE7cbELu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02T= WFy Y28gVGlsb2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3B= BMB CAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQOWNpDAS8IAIko8= kg8 YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLfzZ7gNtprJatBEV6fRotIW7NtT= gFf g79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZ= lfh EOO7LALzyLVXELAxYZplGVSs9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8R= e05 8j1ncd6p4jw6QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC= 6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6ZhVzbaLJW= oAR ebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZYi61xhUK32J6iS6W2Siv0E= GhB U+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0mdRsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRo= SgO yqwZWNnAKF84yDk7IWb3RCOkjDybS4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSd= HYs OHVKEPb0VasVlI1VUJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O= 08z UMLCCCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi8uYfJ= xWw VdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HUR4DxiPdo7PQ1tTJ/k= Zb6 Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6I8qLaN7H41Wh2GM5UZfDwSFgaR5ku= /Kc cRuiIszhNvI9tVH0ex1WooZVMPEpITedqajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2n= Nou 6GZ+clFzXYfk1VkRmYT8SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy= 04S XLkLo0K7Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------7715A392E2E503796FA3AEC8-- --THz910kZ5d4SxHjFbQbEnlhxhnmxfkUCn-- --ltiLYQwnTXjIeq4MOJeb3okMz3dx20mV0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmBNCMcFAwAAAAAACgkQ7iZktA5Y2kPM 3gf+NXfAL18fwHzGDZDYeidgYKx0Qi4+PZP714KuE0xCOsY2DhLeTvaacAKUSyrFKsxDH/4lZ/MD qvX2ioYqF2nRu3b5Ne82RgrEg8QYFJ4mOR6Qu3cHOS5If+Hr6SzLZMybyRyai6iNHeOsUGwon8fX kpwdIIvFiD6oDFGc477owyg19Z8eTb8t1dt9axLUp1nwhCiZVAtMI+TMT1+mFtSlpEqyZSe37nca N2xP7jzOJS742Am8DGM7cZPrbSidyzwiG7OkNUHmBsUWT+Ap2gm+tSXIvs/rWSozmAVQ+361N/Fn 27aMKND2blCKfhyWaRo+ZzrDFLWggNOGlWctydjzzA== =dIxE -----END PGP SIGNATURE----- --ltiLYQwnTXjIeq4MOJeb3okMz3dx20mV0-- From nobody Tue Mar 16 09:43: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 063743A138E; Tue, 16 Mar 2021 09:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzJeYQR07kqC; Tue, 16 Mar 2021 09:43:19 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00056.outbound.protection.outlook.com [40.107.0.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FA03A138B; Tue, 16 Mar 2021 09:43:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B24VE3RTvd52nJVvdxgmqHQbfvY6JyHfmGjEVikRadUWOLgJH/dn74Y8LikMHAoQno1Bqwove6ShfRZf2jmXGMqmcLBrsvgUPlal33pxJS1KGtGWhh4gl+erNU05h8/lUgoGxtf8I+QiEM1QYEbciDG3i1IqYJOgQeMKn2uEE85240SgF3LDlcqS6Kvj3W5YOPiD1hZCpOjSCRWkH3HVO3sYnb8OgrAVNwD2Muswfkq2RlA7jWE3abMM95nTth08EPHpTS7WlQySFRdQ3RoO+JSX2I+AQmyWdkOKfC73qA1XjBLFVgdI33kJ2207TQhuaSapqqSYd39tYz8l5ZQA+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PleulWYIgPZw4vFJ7YiQjqJ4bKdIHoQYy1f/PWzrvz8=; b=n3K7j3/EXk426IhkezwWP7zkQ3sFx7Dwuu2LeM9KNkZxZlKe53f46kXz0kvi0S9Cd2BMEf0f5WISaB/CWglp+CyxRFvlUIARbEehmBNj4Qcldv7vQ0kncUcr7zMfPWPCCszsgabXVS5IIkXVT47Xl4s627aJwhDxI7WSCEjh5JknAL5HNQnERXcicBnfw951tSQVdPIq/kfXrM0xeyOEkJcG0LmOJcgCkToLEEyy2h35e6yPY3CHeBTjm5rkc93rXz0gcMpUqzPFyBdhArhG8agfR8Y+mN89HEcXJ969LIRhttITbRxzBaKNiNmGBTuBbVoH0tp+bl2WfxBYTiGjqA== 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=PleulWYIgPZw4vFJ7YiQjqJ4bKdIHoQYy1f/PWzrvz8=; b=LxuCB2tqWmmqcBtQstVn/OEY8pt6CIl+ELms7ynThLWDtsBQ02VeNcFB+8NveQ+nYXclW2ClgdIlltq/6nMIs1bubI4NsufWlY6KFp5eYwPrZafECo8iQbFWgdyKpOYHJgj1Za5DE4kFdG0RsZHxZ/vw7SYtI3WW27Qy62uW/A0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0440.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Tue, 16 Mar 2021 16:43:15 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3933.032; Tue, 16 Mar 2021 16:43:15 +0000 To: draft-ietf-core-new-block@ietf.org Cc: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> Date: Tue, 16 Mar 2021 17:43:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uCCnvMrVtirrycBcJBXsDSUHmMXmXUcP7" X-Originating-IP: [92.34.17.243] X-ClientProxiedBy: MN2PR07CA0029.namprd07.prod.outlook.com (2603:10b6:208:1a0::39) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.68] (92.34.17.243) by MN2PR07CA0029.namprd07.prod.outlook.com (2603:10b6:208:1a0::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32 via Frontend Transport; Tue, 16 Mar 2021 16:43:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 879e70ce-1144-46ec-1eee-08d8e89a9842 X-MS-TrafficTypeDiagnostic: DB6P189MB0440: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eFxE7qYSgxepqymZCU2k5nU8PypDXGW35mOlRrSktVpL4DReqmJPe/M3fCaIcG0QGyVmCYVFdkg41lRH5+wh0ikN/3BWi1WwUFbAyGlJ62MR810A0M0pOAGhjiR/qvQT8PbvAeWGdOyh7+2jXBP2PiagyZoTI4N5dahMP/nTzReiQog4CfpuU7B09V2wXQmLPrPoVX0LjxNrES7b75Idg/Zs7dlE/Q9mykpi5pIoNhPpEEI5ekw1RECtp09hPIgq5hd66pylGQJh5vBSkixqGn4Q09TAhhTbiROdOy54giUkOHvNg7lWGvN8F5bUT8R0HS2Y85CtHAC/HFkTKMppcctuZrRxZ6bKg+xx0izJDwKyZMEOfT1NFR1qd3mVA2v0VMWslZxkaeKFPrmXP27phK1JeUH6ojz/sxWRJC+1r03cjYmI+CKPFGhYwjupxAHpHdH335/Lq3flF+9fzEvyJi+ERVkLIujSqfQoXe0iDY4dT3icYBWgk2tKtPHn+AVgMGM8wn3EwXfoJefIGU2POx6A9Maszc0HildxTeLjBgeeMI0vz3nzlS7gU4GwwtXHvr4EuTlLi2stcFAK/1E9YBaY4wO0XWwub6aUEUBGbuOuKeoFVxNAA1yx3Pb/mvJk0UrsRQaOYlNn3GxVIqhxM/JPt/J8rAAgMGuE0raMGRvgnWJnW9OR5XhR+F2opu599sxLRSLFf3/Cz3sG7k/KJv89OxDOGiyyxvphSAI1Qnk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(136003)(346002)(396003)(366004)(33964004)(8676002)(52116002)(450100002)(19627235002)(26005)(66946007)(478600001)(83380400001)(8936002)(6916009)(31686004)(6666004)(66556008)(6486002)(21480400003)(31696002)(2906002)(2616005)(36756003)(956004)(316002)(966005)(66574015)(16576012)(5660300002)(16526019)(186003)(235185007)(86362001)(66476007)(44832011)(4326008)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SzQzUm05WnVsV0loNUlPT2RsRHVkMFpWdGlRRGRRSFlBa1pCWEVVUFFPbmZs?= =?utf-8?B?ZVBhWFNPOWNKM1p0Wm9zYlJ1aWpEZ0NsaXgrZ1lsWkJYeDk1emM5L0RzbGRZ?= =?utf-8?B?TVBFWm5NekRZSHErYmZOWjhISVErS0ZWd2pEazV3Z0pkdUk0RWN5ZE1ZMVFJ?= =?utf-8?B?Tm43QXZ3UzkvVjM5aUJGb3hPT3JLOXdUUlU4ZTdZc3BETnpLMDBVUnZad0tP?= =?utf-8?B?Sk8zWXdMZ1dvaCszTlRxT3RHam44TWE0MHp1UnlmWFZDQTZzYWMyQjZUN0lj?= =?utf-8?B?cCtvT054clJiaHdZYVhDaWdrdU9DRlZuTHpOcE53NUpDMVRKUDIwTkJMUTll?= =?utf-8?B?WmVIbGVxS3FUbzlUdE8yZ0tBaWw5bVdndUhzVjFvdmdzMm5ub2RSa3FTODY0?= =?utf-8?B?R3h5L01iTm9XeFpYNVEzT3VsUlBoR0hMTXRrNlZuamtPcjhUL0N2cElnU3A3?= =?utf-8?B?Z0ZVR3Zsa2xKMkpOZm5PNmlVQ2dPbU9hZUZDVW45V2ErM0pHK0tLbTFUZnNs?= =?utf-8?B?c0FkZ21zeGtUSWNDUStHaGxiZENCNjJ4TFJoVmtoZ2UvL3JYSEpRRE5ZZXN6?= =?utf-8?B?SVh6Y2ZXSlVheDlCeWdkbFVKaGdjUlV3bFVZU2kwTmlXWlNzSUZ6cUQ3dmQx?= =?utf-8?B?MUkwMEdVUkZwd2NKTG1yQ2VvMVVrRi9qZ000UTl5UjVqZi9TSFNRakVkZk5O?= =?utf-8?B?T1dwZ1U5Z1hTK0NmRkdsY0JmQThnL0xjVkFnUUtzUjQwSTlLcUJPeGJnblF2?= =?utf-8?B?QVFRTGpReWtFT3F6REp4amx6SUd3Q2xWK09oSktyd01TVGU3amdvUVBIanJk?= =?utf-8?B?TndYTkJQTWJ3SnJMYUg5eXBZb1huOWZIQ05SdnlRcmVrSFpyTEw2dTZKbUxp?= =?utf-8?B?b0RRMjZZU2VBOUt2alZ4WHpObGsvUXFiVFllazBSaENqVHM2dytSWGV0bFpu?= =?utf-8?B?MHptMUZpOHgyZHFZWVlnRlpkOWtnTnlYNGxOZEh6dUl4eHBvOVZYZTI1MmJ1?= =?utf-8?B?Z1J6UnFwVVUvRzlEY0pUQXhYN2xjK0k3Q1NRbTNjdVQyR3lUREl6WCtmYTEv?= =?utf-8?B?aklQTWkwbENScnhwSEpjeG80c1o3Y1dZVXZ4aTliOTFJN1FxS2k2Qm9WbHhj?= =?utf-8?B?OHAzeWdhZ1JydjREWHp3Wmt1Skd4WDNEc1o5ZWRHT1kwcURIb1kySjJ6SXFu?= =?utf-8?B?c1RMRUxBR205eXRBM0ViMjR2d2hYMVRibG83QVZsMG50djZCSEZjUFFWWm5k?= =?utf-8?B?RVZuQzJTUlJTa2Y5Tkh5M2dzd0U4Q3VxNkVMR2dzcG81NzVXWVEzOEdaa3Zp?= =?utf-8?B?eGQwT2UzR0QzMlJpSVFYTU0xVURwcUJLbTNFYVBpRWZ2aGdzWndOaWMyYXM2?= =?utf-8?B?Ymhxd00xbzhwWll5MFcyQWlmaGdEMzhlV1Bha3dxenBWTEdqRW1BbnNyR1NG?= =?utf-8?B?eG1wRS9uQklYNzNWTnprZUUzY1RFQ1lqMFNIWTc5UUNkaEpUL0xrbEtWbWwv?= =?utf-8?B?YmZzdDZBd2U3MzhkZGs3R1d0bjYyekN3VzArSzYyMVlOdWd5VkR4SjRpQVZl?= =?utf-8?B?NGkzRW42VUFsSGZaWGc0Y2s5TkwrNk93R2tYdmd6V01KNHQzejFDRTk1TUMw?= =?utf-8?B?TUkyVmVjOUJyNUhVblVLeDVDQW50UytVMTZXdmNYbjVmZmYrdzd4MHQxSEIx?= =?utf-8?B?Wlo1dWg2TXBnOERZWGhEeU1RR2FNN1ExQndsZS81L1YxQTZ4a2VpYnNXbUs4?= =?utf-8?Q?x5NRzrfLFiKqJvF8wHSGM58FUAsUups7MB597lP?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 879e70ce-1144-46ec-1eee-08d8e89a9842 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2021 16:43:15.2123 (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: A9iYtngeLelEA2zUPCNfOTlyQMbDFrakVY9oJbSxQKcOcyQxynHu3NTntogqAoWM4pPjXCVurwk2WlqOdEZ0fw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0440 Archived-At: Subject: [core] Shepherd review of draft-ietf-core-new-block-08 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 Mar 2021 16:43:23 -0000 --uCCnvMrVtirrycBcJBXsDSUHmMXmXUcP7 Content-Type: multipart/mixed; boundary="0qTIpMCLSPi6T5YYq1igkWxylgzCji47t"; protected-headers="v1" From: Marco Tiloca To: draft-ietf-core-new-block@ietf.org Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> Subject: [core] Shepherd review of draft-ietf-core-new-block-08 --0qTIpMCLSPi6T5YYq1igkWxylgzCji47t Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello Med and Jon, Please, find below my comments from the shepherd review. Best, /Marco [General] * In the document header, replace "CORE" with "CoRE Working Group" [Abstract] * s/Block1 and Block2 Options/Block1 and Block2 Options defined in RFC 79= 59 =C2=A0=C2=A0 Don't include an actual link to RFC 7959, only mention it a= s plaintext * s/interchanges as well/interchanges. Also, they support [Section 1] * In the sentence "These options operate ... has completed.", what's the = subject for "can"? Also, "when the request" seems to relate only to the=20 previous "ask". Proposed overall rephrasing: =C2=A0=C2=A0 These options operate synchronously, i.e., each individual = block has=20 to be requested. A CoAP endpoint can only ask for (or send) the next=20 block when the transfer of the previous block has completed. * s/Packet, and hence/Packet transmission rate, and hence [Section 1.1] * s/(NON) without requiring/(NON) messages without requiring * s/in place for NON/in place when NON messages are used * s/in a single CoAP packet/in a single CoAP message * Proposed rephrasing for "... the receiving CoAP endpoint informs the=20 CoAP sender endpoint either successful receipt or reports on all blocks=20 in the body that have not yet been received." =C2=A0=C2=A0 ... the receiving CoAP endpoint either informs the CoAP sen= der=20 endpoint of successful reception, or reports on all blocks in the body=20 that have not yet been received. * s/If the new option is not supported/If the new options are not support= ed * I think that the paragraph "Q-Block1 and Q-Block2 Options are designed = to work in particular with Non-confirmable requests and responses." fits = better right before the paragraph "Using NON messages, the faster ..." [Section 1.3] * s/that can't use/that cannot use * s/It is not recommended that these options are used/It is NOT=20 RECOMMENDED to use these options [Section 2] * You would expect the reader to be familiar also with RFC 7959 and RFC=20 8132. [Section 3.1] * s/properties of Q-Block1/properties of the Q-Block1 * s/or similar so that/or similar request so that * s/both a class E and a class U in terms of OSCORE/both of class E and=20 class U for OSCORE [Section 3.3] * s/and the resource was created/and that the resource was created * s/and the resource was deleted/and that the resource was deleted * s/and the resource was updated/and that the resource was updated * s/and the appropriate representation/and that the appropriate=20 representation * When discussing the 2.05 (Content) code, why is the exact Token to use = in each notification left unspecified? Shouldn't it be about using the=20 one from the last received payload also in this case? * When discussing the 2.31 (Continue) code, I believe the words "in the=20 response" are a remnant and should be removed. I think it should read: =C2=A0=C2=A0 This Response Code can be used to indicate that all of the = blocks up=20 to and including the Q-Block1 Option block NUM (all having the M bit=20 set) have been successfully received. * Also about 2.31 (Continue): "... and MAX_PAYLOADS (Section 6.2)=20 payloads have been received by the server." Since when? Since the=20 acknowledgment of the previous MAX_PAYLOADS set? * On 4.00 (Bad Request), as non native speaker, I got a bit confused by=20 the combination of "does not"+"both"+"and". Perhaps rephrase as: =C2=A0=C2=A0 "... if the request includes neither a Request-Tag Option n= or a=20 Size1 Option but ..." * "If the server has not received all the payloads ... before sending a=20 4.08 (Request Entity Incomplete) response." =C2=A0=C2=A0 This seems better fitting as a last paragraph in the block = of text=20 above about the 4.08 code. [Section 3.4] * "A client SHOULD only maintain a partial body (missing payloads) for=20 up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age=20 Option ..." =C2=A0=C2=A0 Doesn't this also apply to the retention of the Tokens used= during=20 the body transfer from the server to the client? I couldn't find a given = guidance about the client releasing those Tokens, analogous to the one=20 given in Section 3.1, but I guess it would fit here. * s/with a 2.03 (Valid Response)/with a 2.03 (Valid) Response * s/a triggered Observe/a triggered Observe notification [Section 6.2] * On NON_MAX_RETRANSMIT, "After this occurs, the local endpoint SHOULD=20 consider the body stale and remove all references to it." =C2=A0=C2=A0 It's better to remind what such references are, i.e. Tokens= and=20 Request-Tags on the client, as well as ETags on the server. [Section 7] * s/Q-Block2s/Q-Block2 responses [Section 9] * You can mention that the examples consider MAX_PAYLOADS =3D 10 and=20 NON_MAX_RETRANSMIT =3D 4, just as per the default values in Table 3. [Section 9.1.3] * s/the token that was used in the last block number received=20 payload/the token that was used in the last received payload [Section 9.3.3] * s/where there are some blocks are lost/where some blocks are lost * s/response is be the token/response is the token * s/last block number received payload/last received payload * In Figure 16, the final response with Message ID M:0xa7 should have ET=3D= 24. [Section 10] In all the following subsections, please replace "[RFCXXXX]" with "[This = _Document]", as you do in Section 10.2. [Section 10.1] * Rename the section as "CoAP Option Numbers Registry". * Expand the first sentence as "... "CoAP Option Numbers" sub-registry=20 [Options] defined in [RFC7252] within the "Constrained RESTful=20 Environments (CoRE) Parameters" registry." * Any rationale behind suggesting 51 as option number for Q-Block2 ? The = number is consistent with the intended option properties; however other=20 consistent, smaller and unassigned values are 31, 43 and 47. [Section 10.2] * Rename the section as "Media Type Registrations". * Expand the first sentence as "... [IANA-MediaTypes]. This registration = follows the procedures specified in [RFC6838]." , and add RFC6838 as=20 normative reference. * Expand "Encoding considerations" as: " Must be encoded as a CBOR=20 sequence [RFC8742], as defined in Section 4 of [RFCXXXX]. * In "Security considerations", add an actual link to the section. * In "Applications that use this media type", you should be more=20 specific, e.g.: =C2=A0=C2=A0 The type is used by applications relying on block-wise tran= sfers,=20 allowing a server to specify non-received blocks and request for their=20 retransmission, as defined in Section 4 of [This_Document]. * It's fine to just have "Additional information: N/A". [Section 10.3] * Rename the section as "CoAP Content-Formats Registry". * s/the CoAP Content-Format ID/the following CoAP Content-Format * Expand the first sentence as "... "CoAP Content-Formats" sub-registry=20 [Format], defined in [RFC7252], within the "Constrained RESTful=20 Environments (CoRE) Parameters" registry." [Section 11] * Please swap this section with the previous one. Security=20 considerations come before IANA considerations. [Section 12] * The "Acknowledgements" section should be moved down and be right=20 before the final "Authors Addresses". Also, it must be a non-numbered=20 section. [Section 13] * Refer to version -13 of draft-ietf-core-echo-request-tag [Appendix A.1] * s/the use Q-Block1 Option/the use of Q-Block1 Option * In Figure 18, the notation "--->?" should still be "--->X", like used=20 also in a similar fashion later at the end of Figure 19. --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --0qTIpMCLSPi6T5YYq1igkWxylgzCji47t-- --uCCnvMrVtirrycBcJBXsDSUHmMXmXUcP7 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmBQ4B0FAwAAAAAACgkQ7iZktA5Y2kOy YwgAn6sz18B9v1gC/b0YCWa6H7BnvcgZI08fAWRYqrjSncQtspmd1LrxqqVWSEHYp7d06wWl3UP0 zsb6RzaRPH+NAv3B8sLHIht4c1gWa8PZFdPHkgwT9fJxi6RLZFJpwdyjUEFdrBnqOKVaI71CEzcy PPoqAupW4L75hwSVaDbOHwpP8Om8/L9wxbgeumkqkUg03Qmjrk1BYHgw61lfmYR4n18QsGKv+d7V QUPZ1K4b4lAPE/xf4dMqejSU6XiX/J1miLa6wa9m0Y1+bJP9b+2Kk9qyseGtnzMQNKppBq4c2xa/ 0QAJrIZTlhaGSpWGBDyf2jefqHomqF84tr6xuwZbSw== =SJSb -----END PGP SIGNATURE----- --uCCnvMrVtirrycBcJBXsDSUHmMXmXUcP7-- From nobody Tue Mar 16 10:34:10 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 2571F3A14FB; Tue, 16 Mar 2021 10:34:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: core@ietf.org, draft-ietf-core-sid.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161591604910.2184.1526890406711267425@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Tue, 16 Mar 2021 10:34:09 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:34:09 -0000 Reviewer: Linda Dunbar Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-sid-15 Reviewer: Linda Dunbar Review Date: 2021-03-16 IETF LC End Date: 2021-03-17 IESG Telechat date: Not scheduled for a telechat Summary: This document introduces the globally unique 63-bits integers to identify YANG items which include data nodes, RPCs, their associated inputs/outputs, notifications, YANG modules, submodules, and features. Major issues: - One of the benefits of YANG is its explicit naming and human-understandable notations. It will be a nightmare if all the YANG items are represented by integers. YANG items being represented by integers will be worse than the TYPE values in the TLVs. At least, the TLV types are in the context of the protocols and their messages. - It will be a tremendous amount of work to map all YANG items to globally unique integers. - YANG has been widely deployed without the numbering system. Which environment will need the integer representations? Who will validate the numbers used? How to validate the YANG modules represented by those "integers"? - SID can be mistaken as Segment Identifiers (SID). Suggest using a different name. Minor issues: Nits/editorial comments: Best Regards, Linda Dunbar From nobody Tue Mar 16 10:59:14 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 E77353A08A7; Tue, 16 Mar 2021 10:59:12 -0700 (PDT) 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 QJIY7vYEhnGQ; Tue, 16 Mar 2021 10:59:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB123A08A6; Tue, 16 Mar 2021 10:59:10 -0700 (PDT) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4F0LdS5jD5zyhk; Tue, 16 Mar 2021 18:59:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <161591604910.2184.1526890406711267425@ietfa.amsl.com> Date: Tue, 16 Mar 2021 18:59:08 +0100 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-core-sid.all@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 637610348.285911-b3962ab0ade0c8ecd2947fddcf81c725 Content-Transfer-Encoding: quoted-printable Message-Id: <3FDAB132-A4CA-4E70-9567-125B51AF4CDD@tzi.org> References: <161591604910.2184.1526890406711267425@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:59:13 -0000 Hi Linda, > On 2021-03-16, at 18:34, Linda Dunbar via Datatracker = wrote: >=20 > Reviewer: Linda Dunbar > Review result: Not Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-sid-15 > Reviewer: Linda Dunbar > Review Date: 2021-03-16 > IETF LC End Date: 2021-03-17 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > This document introduces the globally unique 63-bits integers to = identify YANG > items which include data nodes, RPCs, their associated inputs/outputs, > notifications, YANG modules, submodules, and features. >=20 > Major issues: > - One of the benefits of YANG is its explicit naming and = human-understandable > notations. It will be a nightmare if all the YANG items are = represented by > integers. YANG items being represented by integers will be worse than = the TYPE > values in the TLVs. At least, the TLV types are in the context of the = protocols > and their messages. - It will be a tremendous amount of work to map = all YANG > items to globally unique integers. - YANG has been widely deployed = without the > numbering system. Which environment will need the integer = representations? Who > will validate the numbers used? How to validate the YANG modules = represented by > those "integers"? These are all questions that were valid before this document was = written. The document now shows that this can be done, without any of the = disadvantages you cite. There never will be a need to map *all* YANG identifiers to YANG SIDs, = as YANG-CBOR is designed to allow string identifiers as well (you can = use YANG-CBOR entirely without using YANG SIDs). But where encoding and = lookup efficiency is important, YANG SIDs are the way to go, and the = process for allocating and using them that we arrived at after years of = discussion (including several rounds with IANA) makes them very much = workable. > - SID can be mistaken as Segment Identifiers (SID). Suggest using a = different > name. Indeed, that=E2=80=99s why they are called =E2=80=9CYANG SIDs=E2=80=9D. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 16 12:36:33 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CD33A0CB7; Tue, 16 Mar 2021 12:36:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke via Datatracker To: Cc: core@ietf.org, draft-ietf-core-yang-cbor.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161592338136.13562.2421108714318351834@ietfa.amsl.com> Reply-To: Joe Clarke Date: Tue, 16 Mar 2021 12:36:21 -0700 Archived-At: Subject: [core] Yangdoctors last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 19:36:28 -0000 Reviewer: Joe Clarke Review result: Almost Ready I have been asked to review this document on behalf of yang-doctors. Overall, I found the document with its many examples to be quite readable and clear. However, I did find a few readable and typo issues and I have a few questions. See below. === Abstract: s/notifications and yang-data/notifications and the yang-data/ === Section 2: Move the definition of YANG Schema iDentifier higher up in the list of terminology so it's defined before you use it when discussing deltas. This should likely be first in the list. === Section 3 s/When schema node are serialized/When schema nodes are serialized/ === Section 3.3 s/identifiers as string, similar/identifiers as strings, similar/ === Section 4.1 In other examples you include the associated type definition inline. You don't do that with inet:domain-name. In fact, you _do_ include the domain-name typedef in Section 4.3, but I think it should move up here as well to aid in readability. === Section 4.2.1 s/In the case of an 'notification content'/In the case of a 'notification content'/ === Section 4.2.2 You duplicate the YANG snippet here that you included in the overarching Section 4.2. I don't think both are needed. Probably best to drop this here since you didn't include it in 4.2.1. === Section 4.4 You use the term "list instance" to mean what I think is better stated as "list entry". The latter is clearer with respect to an element within a list vs. the instance of a list itself. You use "list instance" in Section 3 as well (and in other places in the document) where I think "list entry" would be clearer. === Section 4.4.1 I think documenting the true/false value of the primitives here (noted in the CBOR encoding) would aid in clarity. For example, "primitive(20) [false]". === Section 4.5.1 I'm being pedantic here, but ahead of the { 60123 : { ... example, you usually state "CBOR diagnostic output". You don't here, though. I think you should add it. === Section 4.6 Concerning text "anyxml value MAY contain CBOR data items tagged with one of the tags listed in Section 9.3, these tags shall be supported.": This sentence fragment makes no sense. Did you mean something along the lines of: "the tags listed in Section 9.3 SHALL be supported"? === Section 5 s/Just like YANG containers, yang-data/Just like YANG containers, the yang-data/ === Section 6.7 s/same example yang definition, but this/same example YANG definition, but this/ s/byte string MUST instead by encoded/byte string MUST instead be encoded/ === Section 6.13.1 It isn't clear to me how a YANG list with multiple keys or a YANG list with no keys would be encoded in CBOR. I think examples and some clarifying text would help. From nobody Tue Mar 16 12:37: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 F01723A0D75 for ; Tue, 16 Mar 2021 12:37:08 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsU97pEht_px for ; Tue, 16 Mar 2021 12:37:05 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 AECD13A0D3C for ; Tue, 16 Mar 2021 12:37:00 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id u20so179436lja.13 for ; Tue, 16 Mar 2021 12:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RiGjp5RrAomcvh3MRkY2zH0NmBMpmqIK/AWHhjrFxk0=; b=guc7802oxckATjzwzMWFVxj4syZwfjJ4g360JDnpWDRILYq57hVHVSe7H8BojnV+83 3iHFqg0PN1+1Lu40ZwccTrf5UkptrfW6E2aKZz7NxceIVAdKAp16w7YSUqHv2IbV2rA8 ndedB0yZxmY7uPomoliFm1pOz+4pfX2GyfADUJdP/va7eRVX4R99DPlvkaKGFFPWaOMC JjX6dQRfC5g9oecOXYsABgDYJ5ysj+9JwM0P5IZai+d9o8b/uaI9Tw7qCg6/Mqdcpmz0 7as0jFexAizLDRO7C2EUroSqyr1OZ7qgfrxVSLiPBzsNiq/VAtmB5rPEIu64FrgXkLPl A7cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RiGjp5RrAomcvh3MRkY2zH0NmBMpmqIK/AWHhjrFxk0=; b=aZQc2Px73KgcE+NYKBnz65/QItRqLzOpj5nzhxcobpI3VMd9Fbk6GBljAvN1gVteIB A++ue39TkolBFAkbJqFQDp+ektfiDswFgeSgkHHUuinx0vPFUcr1urIVzVDhTYkOpybP TcQW2Qd3uZUoqCY3gETAYB4ywJbZG6dioZc6NWY6XS7gv/qxH4QEwdj8BpbQFyTTlIXI rkHmEe9fPFSbpThF48xEJC7fpG1S/0yiwG/FcZDm9IdB4MdiCfEAcR9dHW4rpRg8RFxN lrry8gNXFg85d0bp4Nk8tDISxbr+MdKgfBYpDm2f5y7rrf3CHDPta7PLpi8+G9zXhRmk W2fQ== X-Gm-Message-State: AOAM530yyEWya7mODJ5Kd9bSt8DHaUMlgoRP1NX4ypS0WnhZKYjJo1Fu RAG0nXJ3CZ5pvEITDEWuIgvzCrWvKScuoctByjrqsQ== X-Google-Smtp-Source: ABdhPJxnd1ESYo/L1WJX3L5G9wVdvw2Vu5uvATdwg1j/rPzPY3ay7g4pHCQSbcweb0UD/Mn2WdnfilF5tvqhQJ+VLbw= X-Received: by 2002:a05:651c:2047:: with SMTP id t7mr157955ljo.325.1615923417988; Tue, 16 Mar 2021 12:36:57 -0700 (PDT) MIME-Version: 1.0 References: <161591604910.2184.1526890406711267425@ietfa.amsl.com> In-Reply-To: <161591604910.2184.1526890406711267425@ietfa.amsl.com> From: Andy Bierman Date: Tue, 16 Mar 2021 12:36:47 -0700 Message-ID: To: Linda Dunbar Cc: General Area Review Team , last-call@ietf.org, draft-ietf-core-sid.all@ietf.org, Core Content-Type: multipart/alternative; boundary="00000000000050527d05bdac7d8f" Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 19:37:15 -0000 --00000000000050527d05bdac7d8f Content-Type: text/plain; charset="UTF-8" On Tue, Mar 16, 2021 at 10:34 AM Linda Dunbar via Datatracker < noreply@ietf.org> wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-core-sid-15 > Reviewer: Linda Dunbar > Review Date: 2021-03-16 > IETF LC End Date: 2021-03-17 > IESG Telechat date: Not scheduled for a telechat > > Summary: > This document introduces the globally unique 63-bits integers to identify > YANG > items which include data nodes, RPCs, their associated inputs/outputs, > notifications, YANG modules, submodules, and features. > > Major issues: > - One of the benefits of YANG is its explicit naming and > human-understandable > notations. It will be a nightmare if all the YANG items are represented by > integers. YANG items being represented by integers will be worse than the > TYPE > values in the TLVs. At least, the TLV types are in the context of the > protocols > and their messages. - It will be a tremendous amount of work to map all > YANG > items to globally unique integers. - YANG has been widely deployed without > the > numbering system. Which environment will need the integer representations? > Who > will validate the numbers used? How to validate the YANG modules > represented by > those "integers"? > > My initial reaction to this work was that it would never fly in the wild. But the CORE WG has developed tools and solved many of the problems with YANG SID. There is a great deal of trust required in the tooling and procedures used to manage the mapping of YANG identifiers to globally unique integers. These numbers are not intended for human usage (much like OID strings in SNMP). If the client and server do not agree on the YANG-to-SID mapping, then the protocols will not work (same as OIDs in SNMP). I think the administration plan makes sense, but it is still unproven, especially the delegated subrange name assignments. The mapping files are independent of the YANG modules so there is no need to alter any YANG module to use YANG SID. There is a lot of work creating mapping files instead. ;-) The mappings are not used in YANG modules at all. They are only useful to generate an efficient binary message encoding for YANG data. (Only. The delta-SID encoding is extremely efficient and really needed right now.) Andy - SID can be mistaken as Segment Identifiers (SID). Suggest using a > different > name. > > Minor issues: > > Nits/editorial comments: > > Best Regards, > Linda Dunbar > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000050527d05bdac7d8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 16, 2021 at 10:34 AM Lind= a Dunbar via Datatracker <noreply@ie= tf.org> wrote:
Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-core-sid-15
Reviewer: Linda Dunbar
Review Date: 2021-03-16
IETF LC End Date: 2021-03-17
IESG Telechat date: Not scheduled for a telechat

Summary:
This document introduces the globally unique 63-bits integers to identify Y= ANG
items which include data nodes, RPCs, their associated inputs/outputs,
notifications, YANG modules, submodules, and features.

Major issues:
- One of the benefits of YANG is its explicit naming and human-understandab= le
notations. It will be a nightmare if all the YANG items are represented by<= br> integers. YANG items being represented by integers will be worse than the T= YPE
values in the TLVs. At least, the TLV types are in the context of the proto= cols
and their messages. - It will be a tremendous amount of work to map all YAN= G
items to globally unique integers. - YANG has been widely deployed without = the
numbering system. Which environment will need the integer representations? = Who
will validate the numbers used? How to validate the YANG modules represente= d by
those "integers"?



My initial reaction to = this work was that it would never fly in the wild.
But the CORE W= G has developed tools and solved many of the problems with YANG SID.
<= div>
There is a great deal of trust required in the tooling a= nd procedures used to manage the mapping of
YANG identifiers to g= lobally unique integers.=C2=A0 These numbers are not intended for
human usage (much like OID strings in SNMP).=C2=A0 If the client and serve= r do not agree
on the YANG-to-SID mapping, then the protocols wil= l not work (same as OIDs in SNMP).
I think the administration pla= n makes sense, but it is still unproven, especially the
delegated= subrange name assignments.

The mapping files are = independent of the YANG modules so there is no need to alter
any = YANG module to use YANG SID.=C2=A0 There is a lot of work creating mapping = files instead. ;-)
The mappings are not used in YANG modules at a= ll. They are only useful to generate an
efficient binary message = encoding for YANG data.=C2=A0 (Only. The delta-SID encoding is extremely ef= ficient
and really needed right now.)

Andy


- SID can be mistaken as Segment Identifiers (SID). Suggest using a differe= nt
name.

Minor issues:

Nits/editorial comments:

Best Regards,
Linda Dunbar


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000050527d05bdac7d8f-- From nobody Tue Mar 16 13:10:44 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F523A043E for ; Tue, 16 Mar 2021 13:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvVhWxDP6Gpy for ; Tue, 16 Mar 2021 13:10:39 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728F83A0A86 for ; Tue, 16 Mar 2021 13:10:39 -0700 (PDT) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4F0PY9337CzyVc; Tue, 16 Mar 2021 21:10:37 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 637618236.17892-fad51877ce2bf7a07925a14667a3bebe Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 16 Mar 2021 21:10:36 +0100 Message-Id: <299C6908-F83E-42D3-87B1-883C12075780@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] Content-Format size for yang-cbor 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 Mar 2021 20:10:43 -0000 In the IANA review of draft-ietf-core-yang-cbor, the question was raised = what allocation range should be used for the content-format number for=20= application/yang-data+cbor;id=3Dname I believe this content-type will be used mostly for less size-sensitive = applications, as a name is used for YANG identifiers and not a YANG SID. So I think we are fine in the range: 256-9999 IETF Review or IESG Approval e.g., 260. Any disagreement (or support)? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 16 14:48:01 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D963A1076 for ; Tue, 16 Mar 2021 14:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfL6rQy9AlVf for ; Tue, 16 Mar 2021 14:47:57 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 C87143A1070 for ; Tue, 16 Mar 2021 14:47:57 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id g9so14172090ilc.3 for ; Tue, 16 Mar 2021 14:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jm7HSFsjp+NVSOZq5Tz9KKtIXTrKdBMd3cney6D4lDg=; b=qAc/rDPdGYmncknyQRU3r5FWz+RojUl8FQ0MbhfuMoGR/liPF+qKMibzx3/AdM6de6 Ag1fusuvSgr1fxRN0e6rLRsyeNtc4nWO3Rg1iIsxstR/0jZtwaIlrFENOofZ862XZ6gu 6Z8xZzlFPNjrMASbakRmBneuXjvGcEdVvDduNK7f/Z8CH+bhqSNyJd2FW6iI+x15qlQ/ 8C22A0xw+XfTdz04mGXusEX6W8L0JIn6LtcTOx7RIIfKVaQG6pVNsRh3ibaeRoiKAqyw HpeK6ehnPMGlvT9qJwmGnbLgvRAmCTWTTtqfnQkghrn+RrT2Gpaww03v/WAc/W25IO8O 2NUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jm7HSFsjp+NVSOZq5Tz9KKtIXTrKdBMd3cney6D4lDg=; b=Ze5t1zkX12lD50qBMngtPlrcpZChngmS2q3UpUdXsA6w3224xiizOMwEtCGQnA2VbL NLT7g9Ak2kxjFMbHfC8gun6BfH6w4usUg11Tu5pj8rbg+vfE//TqpdmGhOTE7Ncchrw+ a1SrLOuay1Y8bv9ZiEkGxAo4piBz/xpSmyN7CU3cgETpRHzw176is+0spemCjfiXk39T LAht9jHbEa1xoUE6h5ujQnDREuHB+aJwcGh/HDjQPnvdmOXaGCDSIZFJDnk2daol0snu 8uiP6hqdBMX46vEygSzWCx5zsJBKiapo9GfgLemNTdaDuvQR6cUHTJSlmS77t5DRnY0t YW4Q== X-Gm-Message-State: AOAM532sH/m5VheXQdfFXrQ/NboI/MwuoM+IaWiXD9mwGdE3glUuYgB5 eIoUYNZLJqgdqt5wpAjs8/5gi86AEhlmr+Fy3v8j3uWo84k= X-Google-Smtp-Source: ABdhPJwB/Uy28hIO+asOoyZLnMJK0qW4iJqiKDTn4lHglnFPosveFPjnVAa6qdGQt2vqoSY7XFMSG3NlrV7f/UC5qJo= X-Received: by 2002:a92:c010:: with SMTP id q16mr5605571ild.250.1615931276466; Tue, 16 Mar 2021 14:47:56 -0700 (PDT) MIME-Version: 1.0 References: <299C6908-F83E-42D3-87B1-883C12075780@tzi.org> In-Reply-To: <299C6908-F83E-42D3-87B1-883C12075780@tzi.org> From: Alexander Pelov Date: Tue, 16 Mar 2021 22:47:44 +0100 Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000b7325905bdae5118" Archived-At: Subject: Re: [core] Content-Format size for yang-cbor 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 Mar 2021 21:48:00 -0000 --000000000000b7325905bdae5118 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carsten, I agree with you on the proposed allocation - 260 should do well. Cheers, Alexander On Tue, Mar 16, 2021 at 9:10 PM Carsten Bormann wrote: > In the IANA review of draft-ietf-core-yang-cbor, the question was raised > what allocation range should be used for the content-format number for > > application/yang-data+cbor;id=3Dname > > I believe this content-type will be used mostly for less size-sensitive > applications, as a name is used for YANG identifiers and not a YANG SID. > So I think we are fine in the range: > > 256-9999 IETF Review or IESG Approval > > e.g., 260. > > Any disagreement (or support)? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000b7325905bdae5118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carsten,

I agree with you=C2=A0on = the proposed allocation=C2=A0- 260 should do well.

Cheers,
Alexander



<= div class=3D"gmail_quote">
On Tue, Mar= 16, 2021 at 9:10 PM Carsten Bormann <ca= bo@tzi.org> wrote:
In the IANA review of draft-ietf-core-yang-cbor, the question wa= s raised what allocation range should be used for the content-format number= for

application/yang-data+cbor;id=3Dname

I believe this content-type will be used mostly for less size-sensitive app= lications, as a name is used for YANG identifiers and not a YANG SID.
So I think we are fine in the range:

=C2=A0 =C2=A0256-9999=C2=A0 =C2=A0 IETF Review or IESG Approval

e.g., 260.

Any disagreement (or support)?

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000b7325905bdae5118-- From nobody Tue Mar 16 23:16:45 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 2EE0A3A1BEF; Tue, 16 Mar 2021 23:16:44 -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.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161596180413.20408.484544393597219994@ietfa.amsl.com> Date: Tue, 16 Mar 2021 23:16:44 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 06:16:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-09.txt Pages : 44 Date : 2021-03-16 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options defined in RFC 7959, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges. Also, Q-Block1 and Q-Block2 Options support faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-09 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 16 23:26:21 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 3B6E03A1C2E; Tue, 16 Mar 2021 23:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VxDpZfCXbrZ; Tue, 16 Mar 2021 23:26:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 02A023A1AAD; Tue, 16 Mar 2021 23:26:16 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4F0gCW0pG1z5vhK; Wed, 17 Mar 2021 07:26:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1615962375; bh=Xzo/0yeGI87nXKQaRMINSYaqUFqXZOHlBt/t15JqJI0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=DTJ79SeoCjw7eQtdByhlZ8LUgblti1xNOTbikZfFXnkvB/zTNOf+r/eWB4xyuMkp5 YqAHPgB+UFq92pA1Ppye0xeCpWv3PrF9ibgThIlSPyEcHhLjxTECsR4FYRjVfwMC3Z AFp615FMCxoYz2ze9VRAkCtTEuRK/X3DZ08q0fYcqlwLJ//r11RGVTbyJ2eq/NJq3u e6AqLNogL3eKKAPachZI/A+mWR1rNaBak7Iv4nbQc+meNh0y5VKCRUObeZvBXA13sO FqnYtQFyxHuitRnEEQ5eKSDEGtmZ79yNYhYDI/lvIfTpJjG7yLsaLVrwL74QUuqCbL 2R3L0++ncz+kQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4F0gCW00J5zyQF; Wed, 17 Mar 2021 07:26:14 +0100 (CET) From: To: Marco Tiloca , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] Shepherd review of draft-ietf-core-new-block-08 Thread-Index: AQHXGoOB6GYzz00qWUm8M3rHCOZBXqqHtWpA Date: Wed, 17 Mar 2021 06:26:13 +0000 Message-ID: <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> In-Reply-To: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Shepherd review of draft-ietf-core-new-block-08 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 Mar 2021 06:26:19 -0000 SGkgTWFyY28sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNCkFuIHVwZGF0ZWQgdmVy c2lvbiB0aGF0IGZpeGVzIGFsbW9zdCBhbGwgeW91ciBwb2ludHMgaXMgb25saW5lLiBDaGFuZ2Vz IGNhbiBiZSB0cmFja2VkIGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0wOS4gDQoNCldlIGRpZG4ndCB3ZW50IHdpdGggdGhlIGZv bGxvd2luZyBjaGFuZ2UgcHJvcG9zYWw6ICANCg0KPiAqIHMvSXQgaXMgbm90IHJlY29tbWVuZGVk IHRoYXQgdGhlc2Ugb3B0aW9ucyBhcmUgdXNlZC9JdCBpcyBOT1QNCj4gUkVDT01NRU5ERUQgdG8g dXNlIHRoZXNlIG9wdGlvbnMNCg0KYmVjYXVzZSBpdCBpcyByZWR1bmRhbnQgd2l0aCB0aGlzIHRl eHQgaW4gU2VjdGlvbiAxMDoNCg0KICAgSXQgaXMgTk9UIFJFQ09NTUVOREVEIHRoYXQgdGhlIE5v U2VjIHNlY3VyaXR5IG1vZGUgaXMNCiAgIHVzZWQgaWYgdGhlIFEtQmxvY2sxIGFuZCBRLUJsb2Nr MiBPcHRpb25zIGFyZSB0byBiZSB1c2VkLg0KDQpBbHNvLCBmb3IgdGhpcyBvbmU6DQoNCiINClJl ZmVyIHRvIHZlcnNpb24gLTEzIG9mIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnDQoi DQoNCkkgZG9uJ3Qga25vdyB3aHkgdGhlIGxhdGVzdCB2ZXJzaW9uIGlzIG5vdCBpbmRpY2F0ZWQg YXMgdGhlIGVudHJ5IGlzIGF1dG9tYXRpY2FsbHkgcG9wdWxhdGVkLg0KDQpDaGVlcnMsDQpKb24g JiBNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogY29yZSBbbWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJjbyBUaWxvY2ENCj4g RW52b3nDqcKgOiBtYXJkaSAxNiBtYXJzIDIwMjEgMTc6NDMNCj4gw4DCoDogZHJhZnQtaWV0Zi1j b3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiBDY8KgOiBjb3JlQGlldGYub3JnIFdHIChjb3JlQGll dGYub3JnKSA8Y29yZUBpZXRmLm9yZz4NCj4gT2JqZXTCoDogW2NvcmVdIFNoZXBoZXJkIHJldmll dyBvZiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA4DQo+IA0KPiBIZWxsbyBNZWQgYW5kIEpv biwNCj4gDQo+IFBsZWFzZSwgZmluZCBiZWxvdyBteSBjb21tZW50cyBmcm9tIHRoZSBzaGVwaGVy ZCByZXZpZXcuDQo+IA0KPiBCZXN0LA0KPiAvTWFyY28NCj4gDQo+IA0KPiANCj4gW0dlbmVyYWxd DQo+IA0KPiAqIEluIHRoZSBkb2N1bWVudCBoZWFkZXIsIHJlcGxhY2UgIkNPUkUiIHdpdGggIkNv UkUgV29ya2luZyBHcm91cCINCj4gDQo+IA0KPiBbQWJzdHJhY3RdDQo+IA0KPiAqIHMvQmxvY2sx IGFuZCBCbG9jazIgT3B0aW9ucy9CbG9jazEgYW5kIEJsb2NrMiBPcHRpb25zIGRlZmluZWQgaW4N Cj4gUkZDIDc5NTkNCj4gDQo+ICDCoMKgIERvbid0IGluY2x1ZGUgYW4gYWN0dWFsIGxpbmsgdG8g UkZDIDc5NTksIG9ubHkgbWVudGlvbiBpdCBhcw0KPiBwbGFpbnRleHQNCj4gDQo+ICogcy9pbnRl cmNoYW5nZXMgYXMgd2VsbC9pbnRlcmNoYW5nZXMuIEFsc28sIHRoZXkgc3VwcG9ydA0KPiANCj4g DQo+IFtTZWN0aW9uIDFdDQo+IA0KPiAqIEluIHRoZSBzZW50ZW5jZSAiVGhlc2Ugb3B0aW9ucyBv cGVyYXRlIC4uLiBoYXMgY29tcGxldGVkLiIsIHdoYXQncw0KPiB0aGUgc3ViamVjdCBmb3IgImNh biI/IEFsc28sICJ3aGVuIHRoZSByZXF1ZXN0IiBzZWVtcyB0byByZWxhdGUgb25seQ0KPiB0byB0 aGUgcHJldmlvdXMgImFzayIuIFByb3Bvc2VkIG92ZXJhbGwgcmVwaHJhc2luZzoNCj4gDQo+ICDC oMKgIFRoZXNlIG9wdGlvbnMgb3BlcmF0ZSBzeW5jaHJvbm91c2x5LCBpLmUuLCBlYWNoIGluZGl2 aWR1YWwgYmxvY2sNCj4gaGFzIHRvIGJlIHJlcXVlc3RlZC4gQSBDb0FQIGVuZHBvaW50IGNhbiBv bmx5IGFzayBmb3IgKG9yIHNlbmQpIHRoZQ0KPiBuZXh0IGJsb2NrIHdoZW4gdGhlIHRyYW5zZmVy IG9mIHRoZSBwcmV2aW91cyBibG9jayBoYXMgY29tcGxldGVkLg0KPiANCj4gKiBzL1BhY2tldCwg YW5kIGhlbmNlL1BhY2tldCB0cmFuc21pc3Npb24gcmF0ZSwgYW5kIGhlbmNlDQo+IA0KPiANCj4g W1NlY3Rpb24gMS4xXQ0KPiANCj4gKiBzLyhOT04pIHdpdGhvdXQgcmVxdWlyaW5nLyhOT04pIG1l c3NhZ2VzIHdpdGhvdXQgcmVxdWlyaW5nDQo+IA0KPiAqIHMvaW4gcGxhY2UgZm9yIE5PTi9pbiBw bGFjZSB3aGVuIE5PTiBtZXNzYWdlcyBhcmUgdXNlZA0KPiANCj4gKiBzL2luIGEgc2luZ2xlIENv QVAgcGFja2V0L2luIGEgc2luZ2xlIENvQVAgbWVzc2FnZQ0KPiANCj4gKiBQcm9wb3NlZCByZXBo cmFzaW5nIGZvciAiLi4uIHRoZSByZWNlaXZpbmcgQ29BUCBlbmRwb2ludCBpbmZvcm1zDQo+IHRo ZSBDb0FQIHNlbmRlciBlbmRwb2ludCBlaXRoZXIgc3VjY2Vzc2Z1bCByZWNlaXB0IG9yIHJlcG9y dHMgb24gYWxsDQo+IGJsb2NrcyBpbiB0aGUgYm9keSB0aGF0IGhhdmUgbm90IHlldCBiZWVuIHJl Y2VpdmVkLiINCj4gDQo+ICDCoMKgIC4uLiB0aGUgcmVjZWl2aW5nIENvQVAgZW5kcG9pbnQgZWl0 aGVyIGluZm9ybXMgdGhlIENvQVAgc2VuZGVyDQo+IGVuZHBvaW50IG9mIHN1Y2Nlc3NmdWwgcmVj ZXB0aW9uLCBvciByZXBvcnRzIG9uIGFsbCBibG9ja3MgaW4gdGhlDQo+IGJvZHkgdGhhdCBoYXZl IG5vdCB5ZXQgYmVlbiByZWNlaXZlZC4NCj4gDQo+ICogcy9JZiB0aGUgbmV3IG9wdGlvbiBpcyBu b3Qgc3VwcG9ydGVkL0lmIHRoZSBuZXcgb3B0aW9ucyBhcmUgbm90DQo+IHN1cHBvcnRlZA0KPiAN Cj4gKiBJIHRoaW5rIHRoYXQgdGhlIHBhcmFncmFwaCAiUS1CbG9jazEgYW5kIFEtQmxvY2syIE9w dGlvbnMgYXJlDQo+IGRlc2lnbmVkIHRvIHdvcmsgaW4gcGFydGljdWxhciB3aXRoIE5vbi1jb25m aXJtYWJsZSByZXF1ZXN0cyBhbmQNCj4gcmVzcG9uc2VzLiIgZml0cyBiZXR0ZXIgcmlnaHQgYmVm b3JlIHRoZSBwYXJhZ3JhcGggIlVzaW5nIE5PTg0KPiBtZXNzYWdlcywgdGhlIGZhc3RlciAuLi4i DQo+IA0KPiANCj4gW1NlY3Rpb24gMS4zXQ0KPiANCj4gKiBzL3RoYXQgY2FuJ3QgdXNlL3RoYXQg Y2Fubm90IHVzZQ0KPiANCj4gKiBzL0l0IGlzIG5vdCByZWNvbW1lbmRlZCB0aGF0IHRoZXNlIG9w dGlvbnMgYXJlIHVzZWQvSXQgaXMgTk9UDQo+IFJFQ09NTUVOREVEIHRvIHVzZSB0aGVzZSBvcHRp b25zDQo+IA0KPiANCj4gW1NlY3Rpb24gMl0NCj4gDQo+ICogWW91IHdvdWxkIGV4cGVjdCB0aGUg cmVhZGVyIHRvIGJlIGZhbWlsaWFyIGFsc28gd2l0aCBSRkMgNzk1OSBhbmQNCj4gUkZDDQo+IDgx MzIuDQo+IA0KPiANCj4gW1NlY3Rpb24gMy4xXQ0KPiANCj4gKiBzL3Byb3BlcnRpZXMgb2YgUS1C bG9jazEvcHJvcGVydGllcyBvZiB0aGUgUS1CbG9jazENCj4gDQo+ICogcy9vciBzaW1pbGFyIHNv IHRoYXQvb3Igc2ltaWxhciByZXF1ZXN0IHNvIHRoYXQNCj4gDQo+ICogcy9ib3RoIGEgY2xhc3Mg RSBhbmQgYSBjbGFzcyBVIGluIHRlcm1zIG9mIE9TQ09SRS9ib3RoIG9mIGNsYXNzIEUNCj4gYW5k DQo+IGNsYXNzIFUgZm9yIE9TQ09SRQ0KPiANCj4gDQo+IFtTZWN0aW9uIDMuM10NCj4gDQo+ICog cy9hbmQgdGhlIHJlc291cmNlIHdhcyBjcmVhdGVkL2FuZCB0aGF0IHRoZSByZXNvdXJjZSB3YXMg Y3JlYXRlZA0KPiANCj4gKiBzL2FuZCB0aGUgcmVzb3VyY2Ugd2FzIGRlbGV0ZWQvYW5kIHRoYXQg dGhlIHJlc291cmNlIHdhcyBkZWxldGVkDQo+IA0KPiAqIHMvYW5kIHRoZSByZXNvdXJjZSB3YXMg dXBkYXRlZC9hbmQgdGhhdCB0aGUgcmVzb3VyY2Ugd2FzIHVwZGF0ZWQNCj4gDQo+ICogcy9hbmQg dGhlIGFwcHJvcHJpYXRlIHJlcHJlc2VudGF0aW9uL2FuZCB0aGF0IHRoZSBhcHByb3ByaWF0ZQ0K PiByZXByZXNlbnRhdGlvbg0KPiANCj4gKiBXaGVuIGRpc2N1c3NpbmcgdGhlIDIuMDUgKENvbnRl bnQpIGNvZGUsIHdoeSBpcyB0aGUgZXhhY3QgVG9rZW4gdG8NCj4gdXNlDQo+IGluIGVhY2ggbm90 aWZpY2F0aW9uIGxlZnQgdW5zcGVjaWZpZWQ/IFNob3VsZG4ndCBpdCBiZSBhYm91dCB1c2luZw0K PiB0aGUNCj4gb25lIGZyb20gdGhlIGxhc3QgcmVjZWl2ZWQgcGF5bG9hZCBhbHNvIGluIHRoaXMg Y2FzZT8NCj4gDQo+ICogV2hlbiBkaXNjdXNzaW5nIHRoZSAyLjMxIChDb250aW51ZSkgY29kZSwg SSBiZWxpZXZlIHRoZSB3b3JkcyAiaW4NCj4gdGhlDQo+IHJlc3BvbnNlIiBhcmUgYSByZW1uYW50 IGFuZCBzaG91bGQgYmUgcmVtb3ZlZC4gSSB0aGluayBpdCBzaG91bGQNCj4gcmVhZDoNCj4gDQo+ ICDCoMKgIFRoaXMgUmVzcG9uc2UgQ29kZSBjYW4gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IGFs bCBvZiB0aGUgYmxvY2tzDQo+IHVwDQo+IHRvIGFuZCBpbmNsdWRpbmcgdGhlIFEtQmxvY2sxIE9w dGlvbiBibG9jayBOVU0gKGFsbCBoYXZpbmcgdGhlIE0gYml0DQo+IHNldCkgaGF2ZSBiZWVuIHN1 Y2Nlc3NmdWxseSByZWNlaXZlZC4NCj4gDQo+ICogQWxzbyBhYm91dCAyLjMxIChDb250aW51ZSk6 ICIuLi4gYW5kIE1BWF9QQVlMT0FEUyAoU2VjdGlvbiA2LjIpDQo+IHBheWxvYWRzIGhhdmUgYmVl biByZWNlaXZlZCBieSB0aGUgc2VydmVyLiIgU2luY2Ugd2hlbj8gU2luY2UgdGhlDQo+IGFja25v d2xlZGdtZW50IG9mIHRoZSBwcmV2aW91cyBNQVhfUEFZTE9BRFMgc2V0Pw0KPiANCj4gKiBPbiA0 LjAwIChCYWQgUmVxdWVzdCksIGFzIG5vbiBuYXRpdmUgc3BlYWtlciwgSSBnb3QgYSBiaXQgY29u ZnVzZWQNCj4gYnkNCj4gdGhlIGNvbWJpbmF0aW9uIG9mICJkb2VzIG5vdCIrImJvdGgiKyJhbmQi LiBQZXJoYXBzIHJlcGhyYXNlIGFzOg0KPiANCj4gIMKgwqAgIi4uLiBpZiB0aGUgcmVxdWVzdCBp bmNsdWRlcyBuZWl0aGVyIGEgUmVxdWVzdC1UYWcgT3B0aW9uIG5vciBhDQo+IFNpemUxIE9wdGlv biBidXQgLi4uIg0KPiANCj4gKiAiSWYgdGhlIHNlcnZlciBoYXMgbm90IHJlY2VpdmVkIGFsbCB0 aGUgcGF5bG9hZHMgLi4uIGJlZm9yZSBzZW5kaW5nDQo+IGENCj4gNC4wOCAoUmVxdWVzdCBFbnRp dHkgSW5jb21wbGV0ZSkgcmVzcG9uc2UuIg0KPiANCj4gIMKgwqAgVGhpcyBzZWVtcyBiZXR0ZXIg Zml0dGluZyBhcyBhIGxhc3QgcGFyYWdyYXBoIGluIHRoZSBibG9jayBvZg0KPiB0ZXh0DQo+IGFi b3ZlIGFib3V0IHRoZSA0LjA4IGNvZGUuDQo+IA0KPiANCj4gW1NlY3Rpb24gMy40XQ0KPiANCj4g KiAiQSBjbGllbnQgU0hPVUxEIG9ubHkgbWFpbnRhaW4gYSBwYXJ0aWFsIGJvZHkgKG1pc3Npbmcg cGF5bG9hZHMpDQo+IGZvcg0KPiB1cCB0byBOT05fUEFSVElBTF9USU1FT1VUIChTZWN0aW9uIDYu Mikgb3IgYXMgZGVmaW5lZCBieSB0aGUgTWF4LUFnZQ0KPiBPcHRpb24gLi4uIg0KPiANCj4gIMKg wqAgRG9lc24ndCB0aGlzIGFsc28gYXBwbHkgdG8gdGhlIHJldGVudGlvbiBvZiB0aGUgVG9rZW5z IHVzZWQNCj4gZHVyaW5nDQo+IHRoZSBib2R5IHRyYW5zZmVyIGZyb20gdGhlIHNlcnZlciB0byB0 aGUgY2xpZW50PyBJIGNvdWxkbid0IGZpbmQgYQ0KPiBnaXZlbg0KPiBndWlkYW5jZSBhYm91dCB0 aGUgY2xpZW50IHJlbGVhc2luZyB0aG9zZSBUb2tlbnMsIGFuYWxvZ291cyB0byB0aGUNCj4gb25l DQo+IGdpdmVuIGluIFNlY3Rpb24gMy4xLCBidXQgSSBndWVzcyBpdCB3b3VsZCBmaXQgaGVyZS4N Cj4gDQo+ICogcy93aXRoIGEgMi4wMyAoVmFsaWQgUmVzcG9uc2UpL3dpdGggYSAyLjAzIChWYWxp ZCkgUmVzcG9uc2UNCj4gDQo+ICogcy9hIHRyaWdnZXJlZCBPYnNlcnZlL2EgdHJpZ2dlcmVkIE9i c2VydmUgbm90aWZpY2F0aW9uDQo+IA0KPiANCj4gW1NlY3Rpb24gNi4yXQ0KPiANCj4gKiBPbiBO T05fTUFYX1JFVFJBTlNNSVQsICJBZnRlciB0aGlzIG9jY3VycywgdGhlIGxvY2FsIGVuZHBvaW50 DQo+IFNIT1VMRA0KPiBjb25zaWRlciB0aGUgYm9keSBzdGFsZSBhbmQgcmVtb3ZlIGFsbCByZWZl cmVuY2VzIHRvIGl0LiINCj4gDQo+ICDCoMKgIEl0J3MgYmV0dGVyIHRvIHJlbWluZCB3aGF0IHN1 Y2ggcmVmZXJlbmNlcyBhcmUsIGkuZS4gVG9rZW5zIGFuZA0KPiBSZXF1ZXN0LVRhZ3Mgb24gdGhl IGNsaWVudCwgYXMgd2VsbCBhcyBFVGFncyBvbiB0aGUgc2VydmVyLg0KPiANCj4gDQo+IFtTZWN0 aW9uIDddDQo+IA0KPiAqIHMvUS1CbG9jazJzL1EtQmxvY2syIHJlc3BvbnNlcw0KPiANCj4gDQo+ IFtTZWN0aW9uIDldDQo+IA0KPiAqIFlvdSBjYW4gbWVudGlvbiB0aGF0IHRoZSBleGFtcGxlcyBj b25zaWRlciBNQVhfUEFZTE9BRFMgPSAxMCBhbmQNCj4gTk9OX01BWF9SRVRSQU5TTUlUID0gNCwg anVzdCBhcyBwZXIgdGhlIGRlZmF1bHQgdmFsdWVzIGluIFRhYmxlIDMuDQo+IA0KPiANCj4gW1Nl Y3Rpb24gOS4xLjNdDQo+IA0KPiAqIHMvdGhlIHRva2VuIHRoYXQgd2FzIHVzZWQgaW4gdGhlIGxh c3QgYmxvY2sgbnVtYmVyIHJlY2VpdmVkDQo+IHBheWxvYWQvdGhlIHRva2VuIHRoYXQgd2FzIHVz ZWQgaW4gdGhlIGxhc3QgcmVjZWl2ZWQgcGF5bG9hZA0KPiANCj4gDQo+IFtTZWN0aW9uIDkuMy4z XQ0KPiANCj4gKiBzL3doZXJlIHRoZXJlIGFyZSBzb21lIGJsb2NrcyBhcmUgbG9zdC93aGVyZSBz b21lIGJsb2NrcyBhcmUgbG9zdA0KPiANCj4gKiBzL3Jlc3BvbnNlIGlzIGJlIHRoZSB0b2tlbi9y ZXNwb25zZSBpcyB0aGUgdG9rZW4NCj4gDQo+ICogcy9sYXN0IGJsb2NrIG51bWJlciByZWNlaXZl ZCBwYXlsb2FkL2xhc3QgcmVjZWl2ZWQgcGF5bG9hZA0KPiANCj4gKiBJbiBGaWd1cmUgMTYsIHRo ZSBmaW5hbCByZXNwb25zZSB3aXRoIE1lc3NhZ2UgSUQgTToweGE3IHNob3VsZCBoYXZlDQo+IEVU PTI0Lg0KPiANCj4gDQo+IFtTZWN0aW9uIDEwXQ0KPiANCj4gSW4gYWxsIHRoZSBmb2xsb3dpbmcg c3Vic2VjdGlvbnMsIHBsZWFzZSByZXBsYWNlICJbUkZDWFhYWF0iIHdpdGgNCj4gIltUaGlzDQo+ IF9Eb2N1bWVudF0iLCBhcyB5b3UgZG8gaW4gU2VjdGlvbiAxMC4yLg0KPiANCj4gDQo+IFtTZWN0 aW9uIDEwLjFdDQo+IA0KPiAqIFJlbmFtZSB0aGUgc2VjdGlvbiBhcyAiQ29BUCBPcHRpb24gTnVt YmVycyBSZWdpc3RyeSIuDQo+IA0KPiAqIEV4cGFuZCB0aGUgZmlyc3Qgc2VudGVuY2UgYXMgIi4u LiAiQ29BUCBPcHRpb24gTnVtYmVycyIgc3ViLQ0KPiByZWdpc3RyeQ0KPiBbT3B0aW9uc10gZGVm aW5lZCBpbiBbUkZDNzI1Ml0gd2l0aGluIHRoZSAiQ29uc3RyYWluZWQgUkVTVGZ1bA0KPiBFbnZp cm9ubWVudHMgKENvUkUpIFBhcmFtZXRlcnMiIHJlZ2lzdHJ5LiINCj4gDQo+ICogQW55IHJhdGlv bmFsZSBiZWhpbmQgc3VnZ2VzdGluZyA1MSBhcyBvcHRpb24gbnVtYmVyIGZvciBRLUJsb2NrMiA/ DQo+IFRoZQ0KPiBudW1iZXIgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBpbnRlbmRlZCBvcHRpb24g cHJvcGVydGllczsgaG93ZXZlcg0KPiBvdGhlcg0KPiBjb25zaXN0ZW50LCBzbWFsbGVyIGFuZCB1 bmFzc2lnbmVkIHZhbHVlcyBhcmUgMzEsIDQzIGFuZCA0Ny4NCj4gDQo+IA0KPiBbU2VjdGlvbiAx MC4yXQ0KPiANCj4gKiBSZW5hbWUgdGhlIHNlY3Rpb24gYXMgIk1lZGlhIFR5cGUgUmVnaXN0cmF0 aW9ucyIuDQo+IA0KPiAqIEV4cGFuZCB0aGUgZmlyc3Qgc2VudGVuY2UgYXMgIi4uLiBbSUFOQS1N ZWRpYVR5cGVzXS4gVGhpcw0KPiByZWdpc3RyYXRpb24NCj4gZm9sbG93cyB0aGUgcHJvY2VkdXJl cyBzcGVjaWZpZWQgaW4gW1JGQzY4MzhdLiIgLCBhbmQgYWRkIFJGQzY4MzggYXMNCj4gbm9ybWF0 aXZlIHJlZmVyZW5jZS4NCj4gDQo+ICogRXhwYW5kICJFbmNvZGluZyBjb25zaWRlcmF0aW9ucyIg YXM6ICIgTXVzdCBiZSBlbmNvZGVkIGFzIGEgQ0JPUg0KPiBzZXF1ZW5jZSBbUkZDODc0Ml0sIGFz IGRlZmluZWQgaW4gU2VjdGlvbiA0IG9mIFtSRkNYWFhYXS4NCj4gDQo+ICogSW4gIlNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIiwgYWRkIGFuIGFjdHVhbCBsaW5rIHRvIHRoZSBzZWN0aW9uLg0KPiAN Cj4gKiBJbiAiQXBwbGljYXRpb25zIHRoYXQgdXNlIHRoaXMgbWVkaWEgdHlwZSIsIHlvdSBzaG91 bGQgYmUgbW9yZQ0KPiBzcGVjaWZpYywgZS5nLjoNCj4gDQo+ICDCoMKgIFRoZSB0eXBlIGlzIHVz ZWQgYnkgYXBwbGljYXRpb25zIHJlbHlpbmcgb24gYmxvY2std2lzZSB0cmFuc2ZlcnMsDQo+IGFs bG93aW5nIGEgc2VydmVyIHRvIHNwZWNpZnkgbm9uLXJlY2VpdmVkIGJsb2NrcyBhbmQgcmVxdWVz dCBmb3INCj4gdGhlaXINCj4gcmV0cmFuc21pc3Npb24sIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0 IG9mIFtUaGlzX0RvY3VtZW50XS4NCj4gDQo+ICogSXQncyBmaW5lIHRvIGp1c3QgaGF2ZSAiQWRk aXRpb25hbCBpbmZvcm1hdGlvbjogTi9BIi4NCj4gDQo+IA0KPiBbU2VjdGlvbiAxMC4zXQ0KPiAN Cj4gKiBSZW5hbWUgdGhlIHNlY3Rpb24gYXMgIkNvQVAgQ29udGVudC1Gb3JtYXRzIFJlZ2lzdHJ5 Ii4NCj4gDQo+ICogcy90aGUgQ29BUCBDb250ZW50LUZvcm1hdCBJRC90aGUgZm9sbG93aW5nIENv QVAgQ29udGVudC1Gb3JtYXQNCj4gDQo+ICogRXhwYW5kIHRoZSBmaXJzdCBzZW50ZW5jZSBhcyAi Li4uICJDb0FQIENvbnRlbnQtRm9ybWF0cyIgc3ViLQ0KPiByZWdpc3RyeQ0KPiBbRm9ybWF0XSwg ZGVmaW5lZCBpbiBbUkZDNzI1Ml0sIHdpdGhpbiB0aGUgIkNvbnN0cmFpbmVkIFJFU1RmdWwNCj4g RW52aXJvbm1lbnRzIChDb1JFKSBQYXJhbWV0ZXJzIiByZWdpc3RyeS4iDQo+IA0KPiANCj4gW1Nl Y3Rpb24gMTFdDQo+IA0KPiAqIFBsZWFzZSBzd2FwIHRoaXMgc2VjdGlvbiB3aXRoIHRoZSBwcmV2 aW91cyBvbmUuIFNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIGNvbWUgYmVmb3JlIElBTkEgY29u c2lkZXJhdGlvbnMuDQo+IA0KPiANCj4gW1NlY3Rpb24gMTJdDQo+IA0KPiAqIFRoZSAiQWNrbm93 bGVkZ2VtZW50cyIgc2VjdGlvbiBzaG91bGQgYmUgbW92ZWQgZG93biBhbmQgYmUgcmlnaHQNCj4g YmVmb3JlIHRoZSBmaW5hbCAiQXV0aG9ycyBBZGRyZXNzZXMiLiBBbHNvLCBpdCBtdXN0IGJlIGEg bm9uLW51bWJlcmVkDQo+IHNlY3Rpb24uDQo+IA0KPiANCj4gW1NlY3Rpb24gMTNdDQo+IA0KPiAq IFJlZmVyIHRvIHZlcnNpb24gLTEzIG9mIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFn DQo+IA0KPiANCj4gW0FwcGVuZGl4IEEuMV0NCj4gDQo+ICogcy90aGUgdXNlIFEtQmxvY2sxIE9w dGlvbi90aGUgdXNlIG9mIFEtQmxvY2sxIE9wdGlvbg0KPiANCj4gKiBJbiBGaWd1cmUgMTgsIHRo ZSBub3RhdGlvbiAiLS0tPj8iIHNob3VsZCBzdGlsbCBiZSAiLS0tPlgiLCBsaWtlDQo+IHVzZWQN Cj4gYWxzbyBpbiBhIHNpbWlsYXIgZmFzaGlvbiBsYXRlciBhdCB0aGUgZW5kIG9mIEZpZ3VyZSAx OS4NCj4gDQo+IA0KPiAtLQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGguRC4sIFNlbmlvciBSZXNlYXJj aGVyDQo+IA0KPiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQo+IERpdmlzaW9u IElDVA0KPiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiBTRS0xNjQgNDAg S2lzdGEgKFN3ZWRlbikNCj4gDQo+IFBob25lOiArNDYgKDApNzAgNjAgNDYgNTAxDQo+IGh0dHBz Oi8vd3d3LnJpLnNlDQo+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Mar 17 10:37:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523163A0CE7; Wed, 17 Mar 2021 10:37:45 -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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyFqK6Jw0I7E; Wed, 17 Mar 2021 10:37:41 -0700 (PDT) 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 9DED83A0CE5; Wed, 17 Mar 2021 10:37:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VvRfzvwGWIDprPnupkINOTXtPgPLsWPFPwYDvkEJhiZUrhGFXjiliA8BnIR7CFkIwpTXvuPtuzzI0Dm4fGI1s45wvVcia3w7SpRUEqkII8Gs9ERwOQb1UqWkLW1V/Z0elqCUm6YT3W47mHnAy++GnFdscEnxJNvjDrRXsM1f0lDNiALkS9LUlNf6lx3ObJ6DTdP2r6GHibnizvvQyJ5UurG7cZKp2o+cMIujtNs34UVdJrYIzhstBeK5qH+UL60vm/NGQGhTRv49PmKYmYZljU46Q+UUoq/tsuaaibfN0LKNr/ea3wu5NwVHkH7knCU0X9hGYiEvF8CecrfCw+WGUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yuXKz9S5qNuT13cRmWwiAjC//+pH9k3p7QiZAw32oz4=; b=byNX1WELumZsmA9nPsVt8bb3RM3nE7PxJtlaXWWI7cBpu1nUsjNkSGkwFOChDa4rghyVdg14HmWEnCtLHJk8Nlbs7blL7Nde6l4QmpZaAiAshSXk7FAY1VcET2MHb9p9oy+vUmSdQWiXfa2i9FPDVH+1pBQkZCpDCcxhF9XH8NEQP97U+YvBP81/Z34AD446wTUeHqiYQqlrqetuSmDjZNLHfp3lw4ofit4pEvnqUr7ub5fcf0FA1ql3g9elxOB7HCnUS5FS7lZvdKHpzA1RGzcPa5/tikyZDtDVILhmMvU75Hd05eXH5qTElGfK8uZk3bO97f8jI9IouY1WopyG4g== 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=yuXKz9S5qNuT13cRmWwiAjC//+pH9k3p7QiZAw32oz4=; b=i8HBGx0CHiSdEZHaDRF0o24inJmgdj+ipK0DXCZeqdXhtt4nML2iB/P/f7ft2fKcEVq621j3DJZW62m3Lg5pvN8RWEOoz3YWu3UMvL/66hJM05MxUEUVDTpPElKDpeAkrX9jnqrh/wKLrmDW0U076r5O/L/ecgV8/AkAqBYE3KY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1771.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 17:37:34 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 17:37:34 +0000 To: mohamed.boucadair@orange.com, "draft-ietf-core-new-block@ietf.org" Cc: "core@ietf.org WG (core@ietf.org)" References: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Marco Tiloca Message-ID: Date: Wed, 17 Mar 2021 18:37:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T3hqoxfRgXGNsudS9ugtcB5C4zksK49WE" X-Originating-IP: [45.83.91.228] X-ClientProxiedBy: HE1PR0802CA0003.eurprd08.prod.outlook.com (2603:10a6:3:bd::13) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.10] (45.83.91.228) by HE1PR0802CA0003.eurprd08.prod.outlook.com (2603:10a6:3:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Wed, 17 Mar 2021 17:37:33 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 097f1839-1f44-47f8-c1f5-08d8e96b595c X-MS-TrafficTypeDiagnostic: DB9P189MB1771: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7/XJfdSw+710gXq6yoBRJX4A0HF7UAaHZrMtny0tbFvDBFqPyyWsYrtVRsoJ5ae+Rl48USs9sAROG3yWPAak5pSzJT0pJ1LV+XMQ7DFDkSwFmciqBSFJYURuMztQkZhXBIVGhglB9yJIWxhNo0hEJX7GZaJmvL9636YqPoRLbKH3FJKt3jaumO5A0+yCJuRR+EDRk3u7oGUaisdsLzylDcHlLzYOPvNI28bbtI9nIdzs8or3GOUaP7bAoNsgxML7B5hay8qeGCB/eVefws67mIzCrHzEjWZSlfaSNv0MmZpi2EqexWWrzLFaG8mHz3XNT67MbvWP0OSlb4F4nO87aN8hmaS/qfqCM9MrC1kV3zw0tdnQIl7UxbKwBuirjLOb6setD+nEGU4icW/Z1nPBmpaKeMxWPA+M3fP+QV5C/StoDBABJAnqGRMNoF9DNHrvCyX6f4Eeqd1lR0tRsIARUEc3XU9PeYRi5tPdfd8o2GikhQlHyzjVlSbQn3Z4QKA6Z3btvUp5+/YJAqq6HwVjgZjglavMUYcqX83ve180aexbYr4nygVv7Uj+mxmGboeeAhPvG9HnmNBrjsxi0vsXX5N3lA0dyI3VLlCrwee0r/qwG92zBW/iy19g0Wx0xgrlCGtePjEgiOQvo6oMrK1BfiStEWqPd95iNIZlBrV3VmAWL3pKEfRtbHqrssBkJgxX7kY3TsMYNflaFrHi/xBnOWQPpmMxVFOA7nYhZOrxWlc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(366004)(346002)(39850400004)(235185007)(966005)(2906002)(956004)(66574015)(6916009)(2616005)(86362001)(52116002)(19627235002)(53546011)(5660300002)(31696002)(33964004)(44832011)(6486002)(31686004)(83380400001)(66556008)(66616009)(30864003)(66946007)(66476007)(186003)(16526019)(4326008)(21480400003)(36756003)(8936002)(26005)(8676002)(45080400002)(316002)(16576012)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?M094L3ZWV3BVSmxLSzNqRm1SQ2ZhM084eEM5bVpqN0MxdGE1SmVmUHNXaXhC?= =?utf-8?B?WExIYUQ3RVZBV2JlZFFpcXBBZFdhZncxcXFBb2VrdG1aemROZThpQ3UyUld3?= =?utf-8?B?TFFuSnNEMFkxZDlIR2hOUFZoMFYxSllyTUFkaWlsMExuZ3lmU0lhQndERXZH?= =?utf-8?B?U21qZnZNT0p1YlptMEtUcFdRMTNWYTdTL2tyR3hKSlRZU0U2NEI4eG1lS092?= =?utf-8?B?ZytORHEyUWVtLzhKWmtpZnFqc1NraWwwdnFuclBlUjBVMEc5Rk0vS1NRQ1ZT?= =?utf-8?B?NEkwUXdJQVFFR25LN1dkM0IrNWNKSGQ4SHZBTHFmYk9CdjFjZmk5VFFrTFBO?= =?utf-8?B?SjRqNWw0SzhsVjN0aXZCQTl6ZmFvdU4xNmVWUUc5UHBtYWhzcnZlbnBDa2l4?= =?utf-8?B?em1iVGxndWl6eTA5ZVRQRld2QVVDWTNteGpxV1E0a1VaazJoM1dObEdzUVY0?= =?utf-8?B?ZTZLWEg5aEdZTHZCT0ppaEswVTB6VktDaXdqVGhuRnNHOEY2TEt4c3dBQU12?= =?utf-8?B?SEpXaUt5enNuaE1NNzdwQ0FEMnlxanNEaC9GRThYenVBQ3JPVmxPT2xqNDJW?= =?utf-8?B?OXN0a014VTU2djMxZ01NT290YzErYlBVRUVHaURoU1ZqVHJyS3FyTTh6elVQ?= =?utf-8?B?KzcyOVhwWVMzcXNMZW44bCtVVTZ1dnV5aElvLzFEYlNZK1RJMEE5SEc3TVI5?= =?utf-8?B?KytHNWxURVM3ZmpyeTNQNWVzWUpGblpwellpZUtPNlZML05YZGdHSFF4RUdx?= =?utf-8?B?bVZIRC8yM2xvVlJwZHovcjlwTzNrUHVreXBlOVVyS2VSbnhtYS8xTlF3UWZF?= =?utf-8?B?emo1bW9mMDMrSzhiMlFJdmRTbFg1L0MwNnRzbm1pR0RBUSt6djZXQzJVV1dL?= =?utf-8?B?RTQ2QjdEeFljZktVY216MkZwb3kxMTYzNjMzMzdJTStHUzFQdEtIYXJBaHdY?= =?utf-8?B?NXdXR3RkT2RGaDdac3ZjNDBHWTFBQWJuNVYxdTRUbnpnb2FlY1JIVGJHUi9Q?= =?utf-8?B?N1YyK3RBSEgzQ2dORWxyT2VwanFPZHpJY1I0TnhTcC9zaUE3Y0g3L0dkU3Iw?= =?utf-8?B?ajNmazE0OEhISUJ0MnFQTzVmRnZKU1haSGNKcXprdXEvZVpCQTUvYXRDLzJi?= =?utf-8?B?TjNYWHBIY3FpeUhQd1lnejAwQWdTOHFDeUxBNGtJdTZoOTNoZmEza0JSZ01B?= =?utf-8?B?bFJGZ05MNWVKUDJZQVBVV3pKQVBYb29ZVHZCZEkyZ3pVc2xTcTFHekNhdlhD?= =?utf-8?B?S04yaVB2dHBJanRQU3JLdzExOVlYWFRhczNkYXMvOGw0NVExeXBpSDlibHlP?= =?utf-8?B?aEVlK3NVUGNXWVBtSjdycGRrYVVacll4eGdUSWdScTdJZTdTOUxueTdWbnpV?= =?utf-8?B?ckhnZVp1aHZLWWVzbHdGTU1VVHliUFRQalE2eVlWeVc2OG8rbUhUNVM2R3Qy?= =?utf-8?B?K3Vlc1lmRFJhTXlud0FiWnFUZDNnc0hPWTI3QU1WK2k3NDNhTVVaUXMrSTlW?= =?utf-8?B?Y2l3a3VxVmdIN3RtK0YxMlNjN0xsM3ZCWGtsMStJRGZ2Q29JallMcXB2WXZF?= =?utf-8?B?eno1TFBOY2MzRE5UVno0STBERlFUUkJUS3NLSGtpanV5VCtabGdRbHlKb2Ew?= =?utf-8?B?QmcxTXlyOGJhYzE2NGRzYVFIMm00a21hN2F1cm53b1FIbjkxaW4rdkhhRmM3?= =?utf-8?B?V043dGZ0UGk1UGdGa2ZNWFFzVEhPUklMY3NGSTg1TXpqNFFsMGRvZHpXZ29m?= =?utf-8?Q?hnBmE895k4QLQWqYA2838lxhr2De25YdZqBhIwU?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 097f1839-1f44-47f8-c1f5-08d8e96b595c X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2021 17:37:34.7727 (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: AEXPgFnHdmuEz2Pp4SF5ABhc/+COcG/Mts2XGsgKE1qnJDUsCVTUSD3JOZrfjWyx1Tlza5zUwqSs/ABSWSyu9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1771 Archived-At: Subject: Re: [core] Shepherd review of draft-ietf-core-new-block-08 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 Mar 2021 17:37:45 -0000 --T3hqoxfRgXGNsudS9ugtcB5C4zksK49WE Content-Type: multipart/mixed; boundary="c13CBLGd16dg8gOcq5U0RU6WrU84f0LOG"; protected-headers="v1" From: Marco Tiloca To: mohamed.boucadair@orange.com, "draft-ietf-core-new-block@ietf.org" Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] Shepherd review of draft-ietf-core-new-block-08 References: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> --c13CBLGd16dg8gOcq5U0RU6WrU84f0LOG Content-Type: multipart/mixed; boundary="------------537E257B3C72341065AB5B54" Content-Language: en-US This is a multi-part message in MIME format. --------------537E257B3C72341065AB5B54 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Thanks for the quick update and the revised version! It looks good to me. I will proceed with the write-up and the=20 publication request. Best, /Marco On 2021-03-17 07:26, mohamed.boucadair@orange.com wrote: > Hi Marco, > > Thank you for the review. > > An updated version that fixes almost all your points is online. Changes= can be tracked at: https://eur02.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-new-block-0= 9&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cc0df8e881566480a281608d8e90= d916a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637515591928458819%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi= LCJXVCI6Mn0%3D%7C0&sdata=3Dr7DuNZdtQQHk2zdk1D6du7rnzhcUx1be74JOha%2BG= 4AI%3D&reserved=3D0. > > We didn't went with the following change proposal: > >> * s/It is not recommended that these options are used/It is NOT >> RECOMMENDED to use these options > because it is redundant with this text in Section 10: > > It is NOT RECOMMENDED that the NoSec security mode is > used if the Q-Block1 and Q-Block2 Options are to be used. > > Also, for this one: > > " > Refer to version -13 of draft-ietf-core-echo-request-tag > " > > I don't know why the latest version is not indicated as the entry is au= tomatically populated. > > Cheers, > Jon & Med > >> -----Message d'origine----- >> De=C2=A0: core [mailto:core-bounces@ietf.org] De la part de Marco Tilo= ca >> Envoy=C3=A9=C2=A0: mardi 16 mars 2021 17:43 >> =C3=80=C2=A0: draft-ietf-core-new-block@ietf.org >> Cc=C2=A0: core@ietf.org WG (core@ietf.org) >> Objet=C2=A0: [core] Shepherd review of draft-ietf-core-new-block-08 >> >> Hello Med and Jon, >> >> Please, find below my comments from the shepherd review. >> >> Best, >> /Marco >> >> >> >> [General] >> >> * In the document header, replace "CORE" with "CoRE Working Group" >> >> >> [Abstract] >> >> * s/Block1 and Block2 Options/Block1 and Block2 Options defined in >> RFC 7959 >> >> =C2=A0=C2=A0 Don't include an actual link to RFC 7959, only mention = it as >> plaintext >> >> * s/interchanges as well/interchanges. Also, they support >> >> >> [Section 1] >> >> * In the sentence "These options operate ... has completed.", what's >> the subject for "can"? Also, "when the request" seems to relate only >> to the previous "ask". Proposed overall rephrasing: >> >> =C2=A0=C2=A0 These options operate synchronously, i.e., each individ= ual block >> has to be requested. A CoAP endpoint can only ask for (or send) the >> next block when the transfer of the previous block has completed. >> >> * s/Packet, and hence/Packet transmission rate, and hence >> >> >> [Section 1.1] >> >> * s/(NON) without requiring/(NON) messages without requiring >> >> * s/in place for NON/in place when NON messages are used >> >> * s/in a single CoAP packet/in a single CoAP message >> >> * Proposed rephrasing for "... the receiving CoAP endpoint informs >> the CoAP sender endpoint either successful receipt or reports on all >> blocks in the body that have not yet been received." >> >> =C2=A0=C2=A0 ... the receiving CoAP endpoint either informs the CoAP= sender >> endpoint of successful reception, or reports on all blocks in the >> body that have not yet been received. >> >> * s/If the new option is not supported/If the new options are not >> supported >> >> * I think that the paragraph "Q-Block1 and Q-Block2 Options are >> designed to work in particular with Non-confirmable requests and >> responses." fits better right before the paragraph "Using NON >> messages, the faster ..." >> >> >> [Section 1.3] >> >> * s/that can't use/that cannot use >> >> * s/It is not recommended that these options are used/It is NOT >> RECOMMENDED to use these options >> >> >> [Section 2] >> >> * You would expect the reader to be familiar also with RFC 7959 and >> RFC >> 8132. >> >> >> [Section 3.1] >> >> * s/properties of Q-Block1/properties of the Q-Block1 >> >> * s/or similar so that/or similar request so that >> >> * s/both a class E and a class U in terms of OSCORE/both of class E >> and >> class U for OSCORE >> >> >> [Section 3.3] >> >> * s/and the resource was created/and that the resource was created >> >> * s/and the resource was deleted/and that the resource was deleted >> >> * s/and the resource was updated/and that the resource was updated >> >> * s/and the appropriate representation/and that the appropriate >> representation >> >> * When discussing the 2.05 (Content) code, why is the exact Token to >> use >> in each notification left unspecified? Shouldn't it be about using >> the >> one from the last received payload also in this case? >> >> * When discussing the 2.31 (Continue) code, I believe the words "in >> the >> response" are a remnant and should be removed. I think it should >> read: >> >> =C2=A0=C2=A0 This Response Code can be used to indicate that all of = the blocks >> up >> to and including the Q-Block1 Option block NUM (all having the M bit >> set) have been successfully received. >> >> * Also about 2.31 (Continue): "... and MAX_PAYLOADS (Section 6.2) >> payloads have been received by the server." Since when? Since the >> acknowledgment of the previous MAX_PAYLOADS set? >> >> * On 4.00 (Bad Request), as non native speaker, I got a bit confused >> by >> the combination of "does not"+"both"+"and". Perhaps rephrase as: >> >> =C2=A0=C2=A0 "... if the request includes neither a Request-Tag Opti= on nor a >> Size1 Option but ..." >> >> * "If the server has not received all the payloads ... before sending >> a >> 4.08 (Request Entity Incomplete) response." >> >> =C2=A0=C2=A0 This seems better fitting as a last paragraph in the bl= ock of >> text >> above about the 4.08 code. >> >> >> [Section 3.4] >> >> * "A client SHOULD only maintain a partial body (missing payloads) >> for >> up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age >> Option ..." >> >> =C2=A0=C2=A0 Doesn't this also apply to the retention of the Tokens = used >> during >> the body transfer from the server to the client? I couldn't find a >> given >> guidance about the client releasing those Tokens, analogous to the >> one >> given in Section 3.1, but I guess it would fit here. >> >> * s/with a 2.03 (Valid Response)/with a 2.03 (Valid) Response >> >> * s/a triggered Observe/a triggered Observe notification >> >> >> [Section 6.2] >> >> * On NON_MAX_RETRANSMIT, "After this occurs, the local endpoint >> SHOULD >> consider the body stale and remove all references to it." >> >> =C2=A0=C2=A0 It's better to remind what such references are, i.e. To= kens and >> Request-Tags on the client, as well as ETags on the server. >> >> >> [Section 7] >> >> * s/Q-Block2s/Q-Block2 responses >> >> >> [Section 9] >> >> * You can mention that the examples consider MAX_PAYLOADS =3D 10 and >> NON_MAX_RETRANSMIT =3D 4, just as per the default values in Table 3. >> >> >> [Section 9.1.3] >> >> * s/the token that was used in the last block number received >> payload/the token that was used in the last received payload >> >> >> [Section 9.3.3] >> >> * s/where there are some blocks are lost/where some blocks are lost >> >> * s/response is be the token/response is the token >> >> * s/last block number received payload/last received payload >> >> * In Figure 16, the final response with Message ID M:0xa7 should have >> ET=3D24. >> >> >> [Section 10] >> >> In all the following subsections, please replace "[RFCXXXX]" with >> "[This >> _Document]", as you do in Section 10.2. >> >> >> [Section 10.1] >> >> * Rename the section as "CoAP Option Numbers Registry". >> >> * Expand the first sentence as "... "CoAP Option Numbers" sub- >> registry >> [Options] defined in [RFC7252] within the "Constrained RESTful >> Environments (CoRE) Parameters" registry." >> >> * Any rationale behind suggesting 51 as option number for Q-Block2 ? >> The >> number is consistent with the intended option properties; however >> other >> consistent, smaller and unassigned values are 31, 43 and 47. >> >> >> [Section 10.2] >> >> * Rename the section as "Media Type Registrations". >> >> * Expand the first sentence as "... [IANA-MediaTypes]. This >> registration >> follows the procedures specified in [RFC6838]." , and add RFC6838 as >> normative reference. >> >> * Expand "Encoding considerations" as: " Must be encoded as a CBOR >> sequence [RFC8742], as defined in Section 4 of [RFCXXXX]. >> >> * In "Security considerations", add an actual link to the section. >> >> * In "Applications that use this media type", you should be more >> specific, e.g.: >> >> =C2=A0=C2=A0 The type is used by applications relying on block-wise = transfers, >> allowing a server to specify non-received blocks and request for >> their >> retransmission, as defined in Section 4 of [This_Document]. >> >> * It's fine to just have "Additional information: N/A". >> >> >> [Section 10.3] >> >> * Rename the section as "CoAP Content-Formats Registry". >> >> * s/the CoAP Content-Format ID/the following CoAP Content-Format >> >> * Expand the first sentence as "... "CoAP Content-Formats" sub- >> registry >> [Format], defined in [RFC7252], within the "Constrained RESTful >> Environments (CoRE) Parameters" registry." >> >> >> [Section 11] >> >> * Please swap this section with the previous one. Security >> considerations come before IANA considerations. >> >> >> [Section 12] >> >> * The "Acknowledgements" section should be moved down and be right >> before the final "Authors Addresses". Also, it must be a non-numbered >> section. >> >> >> [Section 13] >> >> * Refer to version -13 of draft-ietf-core-echo-request-tag >> >> >> [Appendix A.1] >> >> * s/the use Q-Block1 Option/the use of Q-Block1 Option >> >> * In Figure 18, the notation "--->?" should still be "--->X", like >> used >> also in a similar fashion later at the end of Figure 19. >> >> >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cc0df8e881566480a28= 1608d8e90d916a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6375155919284= 58819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=3D5Dt6Abd9NI%2Fxn02dCje6ESnpI4PRgid= rxJdNzmpNVts%3D&reserved=3D0 >> > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------537E257B3C72341065AB5B54 Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Za= RDP C4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt0G4Ck= Unq 5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6= NHf EWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QO= XrX MGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpb= G9j YSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLB= BYC AwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JNWDTX6h1MUsgejwj4R= Xs6 UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s86ncVygiDUh9fbSDTcuzOp2qgu9nsc= 8sE sYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4M= xMh mi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0K= nXl AczWxCD3J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZs= zJe TvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZkt= A5Y 2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFboHwJaeKZ6s3dCGpzDlV6bLrRM= 9LN /sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4LK4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgS= E/F 26QK2VL9Y/ur5BHgUI34mUar4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgi= YgG QeDvlisWb9NtsxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxz= s6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFCzwWDB4Yfg= AAK CRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod5Njc1jlXqItPKDXzvmTJA= Cy7 JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF9tNL38mzm8emh5vV3XDy8arElEP7bE9Jf= gm2 3Lm9OEwubbtjLYf0z7poncThsYUuaEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+l= alf GS+9OSv9nJD9mdoTNk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXAC= iGG 0zpK666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVSnWWQF= v/9 2zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As1S6e/OC5Mdo5jQhe0= Ozj u5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgtdoCsRRQQxWME8+V95FqsleNd1QfEU= /jM +HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG= 8x2 rFxUOQ7B2DqmxBrRX3GLokNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ= 84o zNX5q52bRceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUCV= I16 cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggAhFyfi+VlqgIj5= a54 npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35HBXZvuFGn5DHBUYhqBFWTx+H5= zHg GBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47OyDDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+= BF9 wtDs6M6YAs9GdHIDhvUJWGDhOZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmt= JXP +QtZRfSaabFxCVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1v= gai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFufWd/D/9PO= 2eZ HdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1Uxu3gbtJoQ4PbT9rJan4Oe= m7/ NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDzALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6= gEq /+3+KROA0ZKEDWcE2rVEzw4UEv37BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5Z= kaS LN6kFoZPZFhrf0fhlLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4= G4D vUAYt5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13YYlqw= g9A yIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw9EpnqLWkWgm5KbT+J= 9h/ tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPzCf3do08MiLWTRVcrY6pXVTGAF/c41= uC6 520+RFm4ytAfrefNac1+5eZBG5k84sTdV9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKX= XPF djMJtVRWSZ/gzaBE7cbELu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02T= WFy Y28gVGlsb2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3B= BMB CAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQOWNpDAS8IAIko8= kg8 YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLfzZ7gNtprJatBEV6fRotIW7NtT= gFf g79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZ= lfh EOO7LALzyLVXELAxYZplGVSs9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8R= e05 8j1ncd6p4jw6QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC= 6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6ZhVzbaLJW= oAR ebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZYi61xhUK32J6iS6W2Siv0E= GhB U+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0mdRsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRo= SgO yqwZWNnAKF84yDk7IWb3RCOkjDybS4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSd= HYs OHVKEPb0VasVlI1VUJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O= 08z UMLCCCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi8uYfJ= xWw VdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HUR4DxiPdo7PQ1tTJ/k= Zb6 Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6I8qLaN7H41Wh2GM5UZfDwSFgaR5ku= /Kc cRuiIszhNvI9tVH0ex1WooZVMPEpITedqajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2n= Nou 6GZ+clFzXYfk1VkRmYT8SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy= 04S XLkLo0K7Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------537E257B3C72341065AB5B54-- --c13CBLGd16dg8gOcq5U0RU6WrU84f0LOG-- --T3hqoxfRgXGNsudS9ugtcB5C4zksK49WE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmBSPlwFAwAAAAAACgkQ7iZktA5Y2kPa 4Af/TIWbvrGeFQQsFTXUw3fNzeLDyKlnHCArb6fqJm+K5Ykw26T8FoMaP+U51xJtuzjA5mYTeRJw GncuVfPmYxi19fhRASHfCxXhrhKru6KrjyG2QmOp4KvBIoadVRv4PAwYZFJwurB384vrntZLEQzS VtgOqcWQqp9yOzRSK1lrMFfjWGmDykcfdN3/4yEU+BtmsG6+Vje6Luuab/U4dCK7zHGwZM/hBjw/ /BjZWrPDgIOx799jFSOf72pRivUp4uMr/6zsXGVkOUO2dn2ggTJQiu1bsQ+RL1PkwRnQMUiZcvjQ WiV3NBpci/kOoPHMLKI5yL474P2K4l4dXMcQOxs1NQ== =offh -----END PGP SIGNATURE----- --T3hqoxfRgXGNsudS9ugtcB5C4zksK49WE-- From nobody Wed Mar 17 13:10: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 BCF683A12F8 for ; Wed, 17 Mar 2021 13:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 mFmG6q8pse1J for ; Wed, 17 Mar 2021 13:10:39 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3B83A12FA for ; Wed, 17 Mar 2021 13:10:39 -0700 (PDT) Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4F11Vj28j5zyXm; Wed, 17 Mar 2021 21:10:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <299C6908-F83E-42D3-87B1-883C12075780@tzi.org> Date: Wed, 17 Mar 2021 21:10:36 +0100 X-Mao-Original-Outgoing-Id: 637704635.611284-e3c0aacf4731132e23d13cec836cb811 Content-Transfer-Encoding: quoted-printable Message-Id: References: <299C6908-F83E-42D3-87B1-883C12075780@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Content-Format size for yang-cbor (and sid!) 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 Mar 2021 20:10:44 -0000 And, of course the same thing for draft-ietf-core-sid and = application/yang-data+cbor;id=3Dsid. In this case, I believe that YANG-based data structures will not just be = used in the context of the larger interchanges typical of CORECONF, but = also for data structures specified in YANG and interchanged separately. Some of these will be rather small and will benefit from YANG-CBOR=E2=80=99= s delta compression. So I believe going for a one-byte value is more appropriate in this = case. So that the two allocations for id=3Dsid and id=3Dname are a bit more = memorable, I now propose: 264 application/yang-data+cbor;id=3Dname 64 application/yang-data+cbor;id=3Dsid Again, comments welcome. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 18 03:00:44 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0F13A26A4 for ; Thu, 18 Mar 2021 03:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsDj7XcdKNMN for ; Thu, 18 Mar 2021 03:00:41 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 DCDAD3A26A3 for ; Thu, 18 Mar 2021 03:00:40 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id v17so1622613iot.6 for ; Thu, 18 Mar 2021 03:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eP6RcET/MSDxyBnWmJBg+lsgz3LmY6Ks7f7KtWc0xDA=; b=uRAajLTothZD8T6GDB8ghk0ZAP2SEoQgmKlVu3Ckf0+TZGjpxzolTWwdpNZz7tQ2/6 TZPCRm+gyOohzeWDsb7gA4kkBtLmUcQLNYl0btcUB8j6G+SeIvzwtv3cabeDB8D/rGpj sL1iuCA3S9u4js1mmSk4oM2+YwvtTlOAd58GJ5X68K6c0s/b76gtI75oKmIYcEgrfye/ 9GuR6J8a2KR6aRF6ZBMYIn3sKsBm6gGVhI/DhImpSyuVNxwfCziG5kZxHv6TYmD0OGqx uUrVhV6F0PD0Im6KfWSYILmBw1Dyhp9llqSHaqjoB+g65ye8Zf3RXV/URad6Yy1QOw5E pO5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eP6RcET/MSDxyBnWmJBg+lsgz3LmY6Ks7f7KtWc0xDA=; b=MO2cuNGSLxeW3susqNF7Go88QP0GkeE+yHxEuJKkWZBYnlbUbqG6m3F7R8XQjOhUSD 76SL4moLm6IRwAEu5XEP4bSGkYD2/XvsVvVQFShN9Ot5e0oSYY3CpfTgECokCXpTH88h 6ges/ttVTmLWh5qm4l1LUuTs/xwxBaihMKN9hWlVxV7ZpIbjslzWmmjpHd7e1TiLUECN dLCI5Q8kuwXU/6llDC7pWIRdnAxyfXpKyJs5e4hiq5XX98OdosFYxRAjpLTw5GR80Abe W9pCb2KbrdpFAcMNSv6XO0jROFO1wHIfINRjKX+JP6d60om8RkgHFTJQ+2R+60NO1j/F 57Rw== X-Gm-Message-State: AOAM530hg06xjyogX3kVRnYUj0dCkY0Qjld/JXnb0TpGf4xg1CI6QAPp JbWO0Si73WIlpo6C9cb5llSvuZLgKGrzOmNRK9AOLQ== X-Google-Smtp-Source: ABdhPJz0ZPecDBIxkFGjEg4W/xlebBRXuqol6NDqd0ACxXdqUqkgJ5CJ8yY4oSXMCmhma/v/lPqiFg0kVWMQH8lM04U= X-Received: by 2002:a5e:dd09:: with SMTP id t9mr9348063iop.111.1616061638743; Thu, 18 Mar 2021 03:00:38 -0700 (PDT) MIME-Version: 1.0 References: <299C6908-F83E-42D3-87B1-883C12075780@tzi.org> In-Reply-To: From: Alexander Pelov Date: Thu, 18 Mar 2021 11:00:27 +0100 Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000e9ab6905bdccab4d" Archived-At: Subject: Re: [core] Content-Format size for yang-cbor (and sid!) 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 Mar 2021 10:00:43 -0000 --000000000000e9ab6905bdccab4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carsten, Thanks for reading the IANA remarks so quickly and for the proposal. Seems perfect to me. Cheers, Alexander On Wed, Mar 17, 2021 at 9:10 PM Carsten Bormann wrote: > And, of course the same thing for draft-ietf-core-sid and > application/yang-data+cbor;id=3Dsid. > > In this case, I believe that YANG-based data structures will not just be > used in the context of the larger interchanges typical of CORECONF, but > also for data structures specified in YANG and interchanged separately. > Some of these will be rather small and will benefit from YANG-CBOR=E2=80= =99s delta > compression. > So I believe going for a one-byte value is more appropriate in this case. > > So that the two allocations for id=3Dsid and id=3Dname are a bit more > memorable, I now propose: > > 264 application/yang-data+cbor;id=3Dname > 64 application/yang-data+cbor;id=3Dsid > > Again, comments welcome. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000e9ab6905bdccab4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Carsten,

Thanks for reading t= he IANA remarks so=C2=A0quickly and for the proposal.=C2=A0
Seems= perfect to me.

Cheers,
Alexander

On Wed, Mar 17, 2021 at 9:10 PM Carsten Bormann <cabo@tzi.org> wrote:
And, of course the same thing for draft-ietf-core-s= id and application/yang-data+cbor;id=3Dsid.

In this case, I believe that YANG-based data structures will not just be us= ed in the context of the larger interchanges typical of CORECONF, but also = for data structures specified in YANG and interchanged separately.
Some of these will be rather small and will benefit from YANG-CBOR=E2=80=99= s delta compression.
So I believe going for a one-byte value is more appropriate in this case.
So that the two allocations for id=3Dsid and id=3Dname are a bit more memor= able, I now propose:

264 application/yang-data+cbor;id=3Dname
=C2=A064 application/yang-data+cbor;id=3Dsid

Again, comments welcome.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000e9ab6905bdccab4d-- From nobody Thu Mar 18 03:12: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 F16263A26E6; Thu, 18 Mar 2021 03:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r35xnxurcMRj; Thu, 18 Mar 2021 03:12:33 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730F73A26E5; Thu, 18 Mar 2021 03:12:33 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CA202408A6; Thu, 18 Mar 2021 11:12:30 +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 3A6BBD3; Thu, 18 Mar 2021 11:12:29 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:84ce:c882:cc15:d15f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D86F614E; Thu, 18 Mar 2021 11:12:28 +0100 (CET) Received: (nullmailer pid 388104 invoked by uid 1000); Thu, 18 Mar 2021 10:12:28 -0000 Date: Thu, 18 Mar 2021 11:12:28 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Benjamin Kaduk Cc: The IESG , draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca Message-ID: References: <161362172020.28530.15247844895355003249@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xldXQrDEN3HSt/Ry" Content-Disposition: inline In-Reply-To: <161362172020.28530.15247844895355003249@ietfa.amsl.com> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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 Mar 2021 10:12:36 -0000 --xldXQrDEN3HSt/Ry Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ben, thanks for your input, we've now taken a first round on it. While we're editing the results in (from which there'll be a point-to-point response later), one point would profit from earlier feedback: > While I recognize that there is going to be a spectrum of requirements > for determining freshness, I would have expected the far extreme of that > spectrum to include a strongly time-limited single-use cryptographic > nonce (akin to what the ACME protocol of RFC 8555 uses but with time > limit), as well as discussion of some points on the spectrum and which > ones might be more or less appropriate in various cases. I do see some > discussion of different use cases, but not much about the tradeoffs > along the spectrum, and no discussion at all about the strongest > properties that it is possible to obtain with this mechanism. We didn't find any purpose that a strict single-use Echo value would serve. There are cases (which are to become part of the explored spectrum) where an action that requires one very recent event-based Echo value. And when taken, the action produces an event / server state change that makes that Echo value not good for anything any more. Still, there is nothing inherently single-use about the value: For example, it doesn't get used up if included in a safe request performed between when it is obtained and when the action is taken. Do you see any applications where an even stricter usable-once behavior would be useful? Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --xldXQrDEN3HSt/Ry Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmBTJ4gACgkQOY0REtOk veEKLg/+OIXhZzDmSiRYwIUh0JaFLzOjLXxDQ678zqWbHr9XH8xNpZ4gbMzkZBf+ t1eyRR7EZcO2CWGB5Z7XOBu+z/iZjiajzT24mo962NXh5RXSunjGLmJ3TOeUMwdA I5Xo0cpRusmPKAqW/a3o9NrnuaDAcnq5knygtVKPGBbUA5q52u/A3OlwW0Ufkrwg zvpQERqwgAkHgBscVJWg8BlpVOM0MLzR3DARvWXX/BvO/4Rq077eKmoK1+b9VfP2 NvTP+/YysnV3/1/HFw3Dr9k4faJ2xQmWuEKe4JJMhNL9t/TK3Khhg7yUm0KnzdpX 1EdoJFpnpXkFDX1ES+OmgdohZZ0eMmejsE3leTXaQTFWBkpS+liQc1rjssnkfDlR XD5/v0yWXtrrYpLn57DqhzPY+eh7NtoJ40DsHxidknclVGDCN32FqcOCt9jlCOnt ZFjD7t2PT64qYKewAEYJq/0YbdiFCy4VzSgatphKRMbGLERhKeGcNOxUOdCZXxqg UtVfWMYRx9VZf6DXHpL01PGeuHbATLprxkczGWgHKT9qqCzfG/PVjH/9OgUUnSMh poHllwCi7M+2MKNyU39K+eRzkpWteTwtXwf/LJVok9yLxqT14oUVJoW1qINW45B6 c0OAvM8AfBXfmGAeCgLZhGuOwP8kP96vr1N6LJXCsBSeBuk2Lpg= =kqjC -----END PGP SIGNATURE----- --xldXQrDEN3HSt/Ry-- From nobody Thu Mar 18 15:03:10 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 0098C3A0B3A; Thu, 18 Mar 2021 15:03:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Marco Tiloca via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Cc: core-chairs@ietf.org, core@ietf.org, iesg-secretary@ietf.org, marco.tiloca@ri.se Message-ID: <161610498898.31292.18426136597086699476@ietfa.amsl.com> Date: Thu, 18 Mar 2021 15:03:08 -0700 Archived-At: Subject: [core] Publication has been requested for draft-ietf-core-new-block-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 22:03:09 -0000 Marco Tiloca has requested publication of draft-ietf-core-new-block-09 as Proposed Standard on behalf of the CORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ From nobody Sat Mar 20 18:15:18 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 744433A10A7; Sat, 20 Mar 2021 18:15:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Peter Yee via Datatracker To: Cc: core@ietf.org, draft-ietf-core-yang-cbor.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161628931741.12906.14218382588913943918@ietfa.amsl.com> Reply-To: Peter Yee Date: Sat, 20 Mar 2021 18:15:17 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 01:15:18 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-yang-cbor-15 Reviewer: Peter Yee Review Date: 2021-03-20 IETF LC End Date: 2021-03-17 IESG Telechat date: Not scheduled for a telechat Summary: This seems like a straightforward encoding specification draft. While I did not check to see that the example encodings were correct, they appeared logical to the eye. Really, the only thing I have to offer is a small set of nits that mildly improve the readability of the document. [Ready with nits] Major issues: None Minor issues: None Nits/editorial comments: General: Ensure that “i.e.” is followed by a comma. Specific: Page 4, “child” term: insert “or” before “an action output”. Page 4, “item” term: append a comma after submodule. Page 5, section 3, 2nd paragraph, 1st sentence: append a comma after “input”. Change the first “and” to “or” (before “action output”). Page 5, section 3, 3rd paragraph, 2nd sentence: consider inserting “a” before “SID”. Append a comma after “nodes”. Change the “and” to “or”. Page 5, section 3, 5th paragraph, 1st sentence: change “and” to “or”. Page 5, section 3, 6th paragraph, 1st sentence: change the first “node” to “nodes”. Append a comma after “name”. Page 8, section 3.2, 6th bullet item: append a comma after “submodules”. Page 8, section 3.3, 1st paragraph, 1st sentence: change “string” to “strings”. Change “as” after “similar” to “to”. Page 8, section 3.3, 1st paragraph, 2nd sentence: change “to SIDs” to “with SID”. Page 11, section 4.2, 1st paragraph, 1st sentence: consider aligning the capitalization and pluralization of terms in this sentence with the usage in the Abstract. Append a comma after “inputs” (or “input” if you change this sentence to match the Abstract). Page 22, 1st paragraph following the bullet items, 2nd sentence: change comma after to either a period or a semicolon. Page 26, section 5.1, 1st paragraph, 2nd sentence: change the comma to a semicolon. Insert “to” before “the CBOR”. Page 27, section 5.2, 1st paragraph, 2nd sentence: change the comma to a semicolon. Insert “to” before “the CBOR”. Page 29, 1st paragraph: change “a” before “’mtu’” to “an”. Page 35, section 6.10: delete the comma after “identityref”. Insert “as” before both “a YANG Schema” and “a name”. Page 35, section 6.10.1, 2nd sentence: consider changing “as” to “used for”. Page 36, section 6.11, 2nd paragraph: change “a” to “an” before “’is-router’”. Page 37, section 6.12, 2nd paragraph following the bullet items: insert “a” before “CBOR”. Page 39, 3rd paragraph: would it make more sense to change “Schema nodes member” to “Schema node members”? Page 39, 2nd bullet item, 2nd sentence: insert “the” before “top”. Change “follow” to “followed”. Page 41, section 6.13.2, 1st paragraph, 1st sentence: I believe “analogous” makes more sense than “analogical” in this sentence: Page 43, section 8, 2nd paragraph, 2nd sentence: change “of” to “to”. From nobody Thu Mar 25 16:40:24 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0B83A0FCE; Thu, 25 Mar 2021 16:40:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Xufeng Liu via Datatracker To: Cc: core@ietf.org, draft-ietf-core-sid.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161671562340.18744.12200188901217754567@ietfa.amsl.com> Reply-To: Xufeng Liu Date: Thu, 25 Mar 2021 16:40:23 -0700 Archived-At: Subject: [core] Yangdoctors last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 23:40:24 -0000 Reviewer: Xufeng Liu Review result: Ready with Nits This is a review of the YANG module in draft-ietf-core-sid-15. Minor Issues, Nits, and Questions: 1) This module uses the yang-data extension in RFC8040, which was the best choice a few years ago when this draft started. However, RFC8791 has been published so that the YANG structure extension is available now. Has the YANG structure extension been considered to replace the yang-data extension? 2) The container sid-file is missing in the tree diagram in Section 4. RFC8340 specifies the tree format to represent such a yang-data definition. If the YANG structure extension in RFC8791 is used, RFC8791 describes how the tree diagram looks like for such a YANG structure. Also, the top container would not be needed, because a YANG structure is encoded as a 'container'. 3) In the container sid-file, the leaf module-name is optional. What is the assumption when it is not specified? It would be beneficial to clarify in the description statement. 4) In the container sid-file, the leaf sid-file-version is optional. The description says that this number starts at zero. Let’s say that there are two .sid files, one of which does not have the version number and the other one has version number 0. Are they the same? If so, would it be better to have a default statement with a default value of 0? 5) For “list dependency-revision”, the key is module-name. The “mandatory true” statement is not necessary for this leaf because it is a key. 6) Under the “list dependency-revision”, the leaf revision-identifier is specified as “mandatory”. What would this leaf be specified when a dependent module does not have a revision? 7) “list assigment-ranges” should be “list assignment-ranges”. A letter ‘n’ is missing in the current YANG module because of a typo. 8) For “list assignment-ranges”, the key is entry-point. The “mandatory true” statement is not necessary for this leaf because it is a key. 9) As a convention, the node names of “list assignment-ranges” and “list items” should be in the singular form, the same way as “list dependency-revision”, so that they would be “list assignment-range” and “list item”. 10) Since a YANG SID value is globally unique, would it be beneficial to have a statement in the YANG file to describe the requirement formally? This can be easily done by adding the following statement under “list items”: unique "sid"; 11) The format of the YANG file needs to be adjusted. Some of the lines in the .yang file are longer than 69 characters. For example, at line 108 is: o Any subsequent schema node name is in the namespace-qualified form To examine, the command “pyang --ietf --max-line-length 69 FILE” can be used. Before publishing, an RFC editor would normalize the format by using the command “pyang -f yang --keep-comments --yang-line-length 69 FILE”. It would be helpful to run this command now since it may change the lines to be longer than the limit of 69 characters. 12) In the example in Appendix A, the four "module-revision" statements contain “.yang” after the date, not following the pattern rule of the revision-identifier. It seems that the sid generation tool did not take out the extension “.yang”. 13) In Appendix A, the 5th item is: o iana-crypt-hash@2014-04-04.yang (defined in [RFC7317]) but in RFC7317, the revision of iana-crypt-hash is 2014-08-06 14) The following is a thought that may have been discussed before and decided by the WG, but I’d mention it here anyway just in case: Since the scope of a .sid file is for a single YANG file (module), many of the data nodes start with the namespace of this particular module. The “schema-node-path” currently requires an identifier string to always start with a namespace. Because of this requirement, there are many repeated namespace strings in the identifiers of the items. If we assume that the default starting namespace is the module associated with the .sid file, we may shorten the .sid file? - Xufeng From nobody Fri Mar 26 09:18: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 C264D3A2244; Fri, 26 Mar 2021 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 FJAyt2gCV6VS; Fri, 26 Mar 2021 09:18:31 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80055.outbound.protection.outlook.com [40.107.8.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 876873A2242; Fri, 26 Mar 2021 09:18:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QfNyNDKJDzdlzLz2DJhIchNTgbLVAedRCdKisNaY8PWD6agJlDvVT6QR8Eo8HbVTgvfF6d4ZNSAqXIaIUz47EA24fZaPenUJt2C1sQsBkqv8HdYcwknowuLfd5qaZPSpOk03SheIT5C3hw7PkZFCVWWrOd8nq6sezNC/birWxj4wHTHyfIYk9Y8G3a4sIBs4uArTl4ebHzbmUFMqTFkDtxzFhhRDuzpFvnYH8UfypuqMcH8THqna6c5WQp0BR1D8LxLovJy+T8hXRWSS3qenPH+RJLjE4hvkX5zGmQeBiTT9HE8K6tUm1aQfI1Y9PtmoinHrd1nn1iwt1pSMMkoPjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GBaVOo3p0KDrrY/FmzQ/rHmeNWMR9RR0FMIEjo5qqMQ=; b=HsfNK7xq/ouBapocUy+L3XvTx+GO8BX5lMgmmIFlykhzhQ29+aRJypQeksUKZE/9cFSxy8tWTZX/dUKzUQGlSKczKQKKWFiTVIGU9EHeaHTpd/LBvYbMx84zXlT5PbxmIP5onefu12NHTPlowbWh3nQD/dOlMreseQxXV5BUVkT43KpJcfoKSbR/BbCZiPgoS0HUgnTDK+U4ex3mLaQn6gI2rWzbM8g5yxS6KxFBqDcdQie1tLHuSMIREl0RSJ5JvAwg4FhbYZABEVQjdfRayNLErKEpD1Umz1YnzFo3q0/QNoICwf6RZ3GD8yKvfBS0PHKGD8nbvVPbUxEMxX3PUw== 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=GBaVOo3p0KDrrY/FmzQ/rHmeNWMR9RR0FMIEjo5qqMQ=; b=Hh9TkiPYCOjdBL6coXa8AecuHvsxJDcV5fm31H7IjXIVHW9/tcr8sW0gn7Hi4PMsgB+xLHW7mZWjQSUGf4pYVUXzXF+w4p/KsrmupEjalFN05btZ7Qoz5OxJn0ozFFf+OE5ExDI1gHiDSSWpPVESv4dRjjf9jh/bCGhVGTFTFz0= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB3452.eurprd07.prod.outlook.com (2603:10a6:7:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.10; Fri, 26 Mar 2021 16:18:27 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::e922:5ae8:48bb:b796]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::e922:5ae8:48bb:b796%3]) with mapi id 15.20.3977.024; Fri, 26 Mar 2021 16:18:27 +0000 From: Francesca Palombini To: Xufeng Liu , "yang-doctors@ietf.org" CC: "core@ietf.org" , "draft-ietf-core-sid.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-core-sid-15 Thread-Index: AQHXIdBDDthO/EBbFE+UdCEW7n1Qj6qWhG8A Date: Fri, 26 Mar 2021 16:18:27 +0000 Message-ID: <14851067-3EF0-468F-97C7-0EC12A6ED1AC@ericsson.com> References: <161671562340.18744.12200188901217754567@ietfa.amsl.com> In-Reply-To: <161671562340.18744.12200188901217754567@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:c100:d0d6:e209:7a1:6bf0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36bf2075-7e11-4fc3-a32f-08d8f072c9c7 x-ms-traffictypediagnostic: HE1PR07MB3452: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IB+7jrCJeHrRDUpEI53JqyhyDJ2lAJY0fZHz0xnSS1Yfp1OJj3A1Lpe77P0hCTTbaxo37XAczzTWffUIVEKTFA4u5cp0sCwVEBPqfRSIuqV1J8eNCr4KcoeCb5seH0ZMAZZYiHmbvsIwd0c4Wt8EDzOlVfPVFk8Zth3tKakzIjJU1Roqfs0TUbpVyRG6pxsgpCCUUUjICqiQF0/WBOXLwdNfFwYORAoT6Jevw7lN4VDdWTzOQ7YrgYpHZmBvRNqQMtF+qErkNL5b3a8BKMCiyWqg07DyuZQI0M1sY6EaLNMU2ME0+nZdHfc30VjCmMh19ruZJh7B1kbc42LfKzBwwGymTTUW3neGImKEU23APi9xPHrtLViUMrDrBBnd9epOnpbv02LaGSBzvCLupQOgFObGWNUtDH3KVI+ufk1CfbgSQoXDald0mfxx5D8TJnVTUV3lmbAwC3QreX2fidSGprADV7uWhtHtqgX4ZhzjRj1OM7LSKuHjbmlKPq69j+RMIKdtwdmKj1J6w1bg6iHXeL/maDFmU6dsKlWDer1ZMZ4rQS4H/IM6UUUz080ooG+fHFau/T4ufcypS/im0NEAOn1h0Zdeeu3/PhuI+MnIjnxWVe/hMPJGhJGbOBKti6kepTQgyN4Iq2hPnIcbOfteuHlHPGx27ZGX8vHLKKl2ySdNRAJ+wDCgbtIn32oyDFE2 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(39860400002)(396003)(376002)(66446008)(33656002)(66946007)(86362001)(2616005)(2906002)(8936002)(478600001)(66476007)(83380400001)(66556008)(64756008)(76116006)(186003)(71200400001)(4326008)(8676002)(6506007)(5660300002)(36756003)(44832011)(6486002)(38100700001)(110136005)(54906003)(316002)(6512007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Tis3YVh2R2pFd3ltMmZ5OTdXcWVvWUFIczk4S2s3TjVzTk00UDhWR1YrOXoz?= =?utf-8?B?SVkyV1RrY1N4MHJuQnhPQmRkY2M3UTV3SmRKSXdtTVl6TGRVU3Q4U2pDZC9V?= =?utf-8?B?dWxDR3Q2RjFUd1VFcVMrN3RXWS9zTVB3YWFHbUpBU2dOckR3YkdVcVdwSDM4?= =?utf-8?B?eTI3TlJHamlpUkRhWEgyaG9tREFCaUk5OStmUWdyTEJ0VmVqbkNtVFVPUHk5?= =?utf-8?B?L3REaWdjbk9OWDlLMUc1VEtybU9CUkd3S2VCcG9HZ0dHb3NmNi9PTlpVcy82?= =?utf-8?B?ZGdOeDNHeTVORDloMWhGT2V1NzQrZFNUVXdYbmt6WUNNN0dwUVNOTlpzQ1Z3?= =?utf-8?B?dXNWODIvQVEyMXRxaUFrSDBZN0JldUhXZmlnVk4wT0p3bzNUYmJwaXFqN1Nu?= =?utf-8?B?eHU3d0pmMFZhMDVkd0tyU0NJSHljMkwvRzQ2aGJiYmpLaUlGWHpzaTRFSG9j?= =?utf-8?B?S2hTNXhUU25WS1NTRzlPeGNyaDlGcTF1Y1pOVi9FdGlTc1hxVzl0SndrM0hG?= =?utf-8?B?U3liVDN5UllQT2FVb3Fvak5nM3JnRWFqY3EyQXUrWTl2TU9mV0k2anZOQTF1?= =?utf-8?B?cVJTaWFLV3ZmSE95MkRoVkpXcDlMUU5JcFkxeFNHVGVDMTYxeTZnNWRJcXlR?= =?utf-8?B?S2REbUttYmh6NGRwSmZCV0p4cWc2NzJJbnlZQ25ERFBTcXZiOGpHZHVNZzJN?= =?utf-8?B?NVorQ3p6R3huckRJajFNajlSWS9BeE81MlFBbGJQK0lheUpNSWNhY3RVOVFW?= =?utf-8?B?djh1T0ZZSHJMa1U1cHFha2k2WHluWEY2L3FCOE91KzBVQTFJNHdXYitxSlFS?= =?utf-8?B?Wm9ZTzB1allUdFloY3RlRi9mZ2QzeE1SVHFuQkZUbmdVVzIwcEFVa3J2Wlgy?= =?utf-8?B?UEYxWThFazNKUkJEb0FLa0pJdFRRalRZc1JRL3pSclFZY1dLblZTbVZXblho?= =?utf-8?B?TEhXSE8xTEJoNzFVZFMwblN1ZGdPc1lmT05yTU9LT3c1dHJWSG5JOXNYTTBL?= =?utf-8?B?L2JDd25WNExzWGtjYTVZZjZLV1RyU0tQcFVKY29lalQraHhHUHoyUWVGeitl?= =?utf-8?B?QlRmNEIyaFFLZWc2WWRSWWhBYXRVMlNwRTEvY05xOVEzOWRnSzVtemF6dFNH?= =?utf-8?B?OWdOT2JlWHpBNkt3ZlllTjVKYmVEaklWMHhXaXQ1N2VCL1BUaEU4TFNhb3VO?= =?utf-8?B?NDFwWmVJSm8rbkhSdStEcW9naTVZRDNUYjlkZWRzMG5oTzdEd1cwblU1QXZL?= =?utf-8?B?dFhPZ3JsbVVpaXdNc1BTeFpQSUVNbkw5OEZ2YTVUeGFPUFMwOHIxWFZoN1h6?= =?utf-8?B?R1NIV3lDblJUbCs1R0JkM25IdEEzODR3ODVENlpuTGhTdUVuYit6b3VFZXJ4?= =?utf-8?B?NjBHNis5VHNyTHdvQ2FlTjA3bDNEMVNKcW9nNDJzWlE2S1lIbUVUckdXZzRl?= =?utf-8?B?b3R4Q2JYQVN6RHIrU2tkTFZvb3RJTHN6N0twKzJnOE42bE9pZitiWjVsNnZG?= =?utf-8?B?NXg1N2R1MDJERkhEc3F5dGhuMEFMWUZoUUltWGZFZEN2Znc0dDJtVUl0Smh3?= =?utf-8?B?eTBObVV6Uzk1dFhFZTJ6TWszMEtMQzY4R2FTZnp2MnVxZVBYVkMyWndDUlVS?= =?utf-8?B?NExEUTJZVTdINVp6cTBUNldzenJOS1hyKzRadnNKSkZreHRUdDloVnQ1M0Ew?= =?utf-8?B?N04wQ0ZVZFQxdnU4NFl1NnVnTjNtZ2lkdmVhSi90bUNRU3NTaXBoY2Y2Q0NX?= =?utf-8?B?QWtLdWQ4UGVZYTF3RlBJZzZ0ZUZodEROcVpLS0h2ZkxWb0EycHI3MGN0SFJE?= =?utf-8?B?c0xydHR6aEE5Q2E2MkFkYXJVTFVaVk5lTzhLTFNVd0xIdEppdmpJQ1kxUzYr?= =?utf-8?B?ai9ubkt3dldaUERCd1lRMzFnSnJnZXQwZysxNlRXN0JQMkE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <622F150154BE58408B70555A93E28D19@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: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36bf2075-7e11-4fc3-a32f-08d8f072c9c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2021 16:18:27.3328 (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: laF3HAkz78xMgLEcNh/8QNAnfCNM4Q3dkM5keSs4Jy5qb0IsiQzVU2f+7P4z4Cv614T4OPJXKa2kBDj9MkdIx0qMVQQM394xBw6H6fWVO0a/6u7S4Y3SGHRlrDLQ4UNT X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3452 Archived-At: Subject: Re: [core] Yangdoctors last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 16:18:36 -0000 WHVmZW5nLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3ISAN Cg0KQXV0aG9yczogcGxlYXNlIGFkZHJlc3MgWHVmZW5nJ3MgY29tbWVudHMgdG9nZXRoZXIgd2l0 aCB0aGUgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHJlY2VpdmVkLg0KDQpUaGFua3MsDQpGcmFu Y2VzY2ENCg0K77u/T24gMjYvMDMvMjAyMSwgMDA6NDAsICJYdWZlbmcgTGl1IHZpYSBEYXRhdHJh Y2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgUmV2aWV3ZXI6IFh1ZmVuZyBM aXUNCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMNCg0KICAgIFRoaXMgaXMgYSBy ZXZpZXcgb2YgdGhlIFlBTkcgbW9kdWxlIGluIGRyYWZ0LWlldGYtY29yZS1zaWQtMTUuDQoNCiAg ICBNaW5vciBJc3N1ZXMsIE5pdHMsIGFuZCBRdWVzdGlvbnM6DQoNCiAgICAxKSBUaGlzIG1vZHVs ZSB1c2VzIHRoZSB5YW5nLWRhdGEgZXh0ZW5zaW9uIGluIFJGQzgwNDAsIHdoaWNoIHdhcyB0aGUg YmVzdA0KICAgIGNob2ljZSBhIGZldyB5ZWFycyBhZ28gd2hlbiB0aGlzIGRyYWZ0IHN0YXJ0ZWQu IEhvd2V2ZXIsIFJGQzg3OTEgaGFzIGJlZW4NCiAgICBwdWJsaXNoZWQgc28gdGhhdCB0aGUgWUFO RyBzdHJ1Y3R1cmUgZXh0ZW5zaW9uIGlzIGF2YWlsYWJsZSBub3cuIEhhcyB0aGUgWUFORw0KICAg IHN0cnVjdHVyZSBleHRlbnNpb24gYmVlbiBjb25zaWRlcmVkIHRvIHJlcGxhY2UgdGhlIHlhbmct ZGF0YSBleHRlbnNpb24/DQoNCiAgICAyKSBUaGUgY29udGFpbmVyIHNpZC1maWxlIGlzIG1pc3Np bmcgaW4gdGhlIHRyZWUgZGlhZ3JhbSBpbiBTZWN0aW9uIDQuIFJGQzgzNDANCiAgICBzcGVjaWZp ZXMgdGhlIHRyZWUgZm9ybWF0IHRvIHJlcHJlc2VudCBzdWNoIGEgeWFuZy1kYXRhIGRlZmluaXRp b24uIElmIHRoZSBZQU5HDQogICAgc3RydWN0dXJlIGV4dGVuc2lvbiBpbiBSRkM4NzkxIGlzIHVz ZWQsIFJGQzg3OTEgZGVzY3JpYmVzIGhvdyB0aGUgdHJlZSBkaWFncmFtDQogICAgbG9va3MgbGlr ZSBmb3Igc3VjaCBhIFlBTkcgc3RydWN0dXJlLiBBbHNvLCB0aGUgdG9wIGNvbnRhaW5lciB3b3Vs ZCBub3QgYmUNCiAgICBuZWVkZWQsIGJlY2F1c2UgYSBZQU5HIHN0cnVjdHVyZSBpcyBlbmNvZGVk IGFzIGEgJ2NvbnRhaW5lcicuDQoNCiAgICAzKSBJbiB0aGUgY29udGFpbmVyIHNpZC1maWxlLCB0 aGUgbGVhZiBtb2R1bGUtbmFtZSBpcyBvcHRpb25hbC4gV2hhdCBpcyB0aGUNCiAgICBhc3N1bXB0 aW9uIHdoZW4gaXQgaXMgbm90IHNwZWNpZmllZD8gSXQgd291bGQgYmUgYmVuZWZpY2lhbCB0byBj bGFyaWZ5IGluIHRoZQ0KICAgIGRlc2NyaXB0aW9uIHN0YXRlbWVudC4NCg0KICAgIDQpIEluIHRo ZSBjb250YWluZXIgc2lkLWZpbGUsIHRoZSBsZWFmIHNpZC1maWxlLXZlcnNpb24gaXMgb3B0aW9u YWwuIFRoZQ0KICAgIGRlc2NyaXB0aW9uIHNheXMgdGhhdCB0aGlzIG51bWJlciBzdGFydHMgYXQg emVyby4gTGV04oCZcyBzYXkgdGhhdCB0aGVyZSBhcmUgdHdvDQogICAgLnNpZCBmaWxlcywgb25l IG9mIHdoaWNoIGRvZXMgbm90IGhhdmUgdGhlIHZlcnNpb24gbnVtYmVyIGFuZCB0aGUgb3RoZXIg b25lIGhhcw0KICAgIHZlcnNpb24gbnVtYmVyIDAuIEFyZSB0aGV5IHRoZSBzYW1lPyBJZiBzbywg d291bGQgaXQgYmUgYmV0dGVyIHRvIGhhdmUgYQ0KICAgIGRlZmF1bHQgc3RhdGVtZW50IHdpdGgg YSBkZWZhdWx0IHZhbHVlIG9mIDA/DQoNCiAgICA1KSBGb3Ig4oCcbGlzdCBkZXBlbmRlbmN5LXJl dmlzaW9u4oCdLCB0aGUga2V5IGlzIG1vZHVsZS1uYW1lLiBUaGUgIOKAnG1hbmRhdG9yeQ0KICAg IHRydWXigJ0gc3RhdGVtZW50IGlzIG5vdCBuZWNlc3NhcnkgZm9yIHRoaXMgbGVhZiBiZWNhdXNl IGl0IGlzIGEga2V5Lg0KDQogICAgNikgVW5kZXIgdGhlIOKAnGxpc3QgZGVwZW5kZW5jeS1yZXZp c2lvbuKAnSwgdGhlIGxlYWYgcmV2aXNpb24taWRlbnRpZmllciBpcw0KICAgIHNwZWNpZmllZCBh cyDigJxtYW5kYXRvcnnigJ0uIFdoYXQgd291bGQgdGhpcyBsZWFmIGJlIHNwZWNpZmllZCB3aGVu IGEgZGVwZW5kZW50DQogICAgbW9kdWxlIGRvZXMgbm90IGhhdmUgYSByZXZpc2lvbj8NCg0KICAg IDcpIOKAnGxpc3QgYXNzaWdtZW50LXJhbmdlc+KAnSBzaG91bGQgYmUg4oCcbGlzdCBhc3NpZ25t ZW50LXJhbmdlc+KAnS4gQSBsZXR0ZXIg4oCYbuKAmSBpcw0KICAgIG1pc3NpbmcgaW4gdGhlIGN1 cnJlbnQgWUFORyBtb2R1bGUgYmVjYXVzZSBvZiBhIHR5cG8uDQoNCiAgICA4KSBGb3Ig4oCcbGlz dCBhc3NpZ25tZW50LXJhbmdlc+KAnSwgdGhlIGtleSBpcyBlbnRyeS1wb2ludC4gVGhlICDigJxt YW5kYXRvcnkgdHJ1ZeKAnQ0KICAgIHN0YXRlbWVudCBpcyBub3QgbmVjZXNzYXJ5IGZvciB0aGlz IGxlYWYgYmVjYXVzZSBpdCBpcyBhIGtleS4NCg0KICAgIDkpIEFzIGEgY29udmVudGlvbiwgdGhl IG5vZGUgbmFtZXMgb2Yg4oCcbGlzdCBhc3NpZ25tZW50LXJhbmdlc+KAnSBhbmQg4oCcbGlzdCBp dGVtc+KAnQ0KICAgIHNob3VsZCBiZSBpbiB0aGUgc2luZ3VsYXIgZm9ybSwgdGhlIHNhbWUgd2F5 IGFzIOKAnGxpc3QgZGVwZW5kZW5jeS1yZXZpc2lvbuKAnSwgc28NCiAgICB0aGF0IHRoZXkgd291 bGQgYmUg4oCcbGlzdCBhc3NpZ25tZW50LXJhbmdl4oCdIGFuZCDigJxsaXN0IGl0ZW3igJ0uDQoN CiAgICAxMCkgU2luY2UgYSBZQU5HIFNJRCB2YWx1ZSBpcyBnbG9iYWxseSB1bmlxdWUsIHdvdWxk IGl0IGJlIGJlbmVmaWNpYWwgdG8gaGF2ZSBhDQogICAgc3RhdGVtZW50IGluIHRoZSBZQU5HIGZp bGUgdG8gZGVzY3JpYmUgdGhlIHJlcXVpcmVtZW50IGZvcm1hbGx5PyBUaGlzIGNhbiBiZQ0KICAg IGVhc2lseSBkb25lIGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCB1bmRlciDigJxs aXN0IGl0ZW1z4oCdOg0KICAgICAgICAgICAgdW5pcXVlICJzaWQiOw0KDQogICAgMTEpIFRoZSBm b3JtYXQgb2YgdGhlIFlBTkcgZmlsZSBuZWVkcyB0byBiZSBhZGp1c3RlZC4gU29tZSBvZiB0aGUg bGluZXMgaW4gdGhlDQogICAgLnlhbmcgZmlsZSBhcmUgbG9uZ2VyIHRoYW4gNjkgY2hhcmFjdGVy cy4gRm9yIGV4YW1wbGUsIGF0IGxpbmUgMTA4IGlzOg0KICAgICAgICAgICBvICBBbnkgc3Vic2Vx dWVudCBzY2hlbWEgbm9kZSBuYW1lIGlzIGluIHRoZSBuYW1lc3BhY2UtcXVhbGlmaWVkIGZvcm0N CiAgICBUbyBleGFtaW5lLCB0aGUgY29tbWFuZCDigJxweWFuZyAtLWlldGYgLS1tYXgtbGluZS1s ZW5ndGggNjkgRklMReKAnSBjYW4gYmUgdXNlZC4NCiAgICBCZWZvcmUgcHVibGlzaGluZywgYW4g UkZDIGVkaXRvciB3b3VsZCBub3JtYWxpemUgdGhlIGZvcm1hdCBieSB1c2luZyB0aGUNCiAgICBj b21tYW5kIOKAnHB5YW5nIC1mIHlhbmcgLS1rZWVwLWNvbW1lbnRzIC0teWFuZy1saW5lLWxlbmd0 aCA2OSBGSUxF4oCdLiBJdCB3b3VsZCBiZQ0KICAgIGhlbHBmdWwgdG8gcnVuIHRoaXMgY29tbWFu ZCBub3cgc2luY2UgaXQgbWF5IGNoYW5nZSB0aGUgbGluZXMgdG8gYmUgbG9uZ2VyIHRoYW4NCiAg ICB0aGUgbGltaXQgb2YgNjkgY2hhcmFjdGVycy4NCg0KICAgIDEyKSBJbiB0aGUgZXhhbXBsZSBp biBBcHBlbmRpeCBBLCB0aGUgZm91ciAibW9kdWxlLXJldmlzaW9uIiBzdGF0ZW1lbnRzIGNvbnRh aW4NCiAgICDigJwueWFuZ+KAnSBhZnRlciB0aGUgZGF0ZSwgbm90IGZvbGxvd2luZyB0aGUgcGF0 dGVybiBydWxlIG9mIHRoZQ0KICAgIHJldmlzaW9uLWlkZW50aWZpZXIuIEl0IHNlZW1zIHRoYXQg dGhlIHNpZCBnZW5lcmF0aW9uIHRvb2wgZGlkIG5vdCB0YWtlIG91dCB0aGUNCiAgICBleHRlbnNp b24g4oCcLnlhbmfigJ0uDQoNCiAgICAxMykgSW4gQXBwZW5kaXggQSwgdGhlIDV0aCBpdGVtIGlz Og0KICAgICBvICBpYW5hLWNyeXB0LWhhc2hAMjAxNC0wNC0wNC55YW5nIChkZWZpbmVkIGluIFtS RkM3MzE3XSkNCiAgICBidXQgaW4gIFJGQzczMTcsIHRoZSByZXZpc2lvbiBvZiAgaWFuYS1jcnlw dC1oYXNoIGlzIDIwMTQtMDgtMDYNCg0KICAgIDE0KSBUaGUgZm9sbG93aW5nIGlzIGEgdGhvdWdo dCB0aGF0IG1heSBoYXZlIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSBhbmQgZGVjaWRlZA0KICAgIGJ5 IHRoZSBXRywgYnV0IEnigJlkIG1lbnRpb24gaXQgaGVyZSBhbnl3YXkganVzdCBpbiBjYXNlOiBT aW5jZSB0aGUgc2NvcGUgb2YgYQ0KICAgIC5zaWQgZmlsZSBpcyBmb3IgYSBzaW5nbGUgWUFORyBm aWxlIChtb2R1bGUpLCBtYW55IG9mIHRoZSBkYXRhIG5vZGVzIHN0YXJ0IHdpdGgNCiAgICB0aGUg bmFtZXNwYWNlIG9mIHRoaXMgcGFydGljdWxhciBtb2R1bGUuIFRoZSDigJxzY2hlbWEtbm9kZS1w YXRo4oCdIGN1cnJlbnRseQ0KICAgIHJlcXVpcmVzIGFuIGlkZW50aWZpZXIgc3RyaW5nIHRvIGFs d2F5cyBzdGFydCB3aXRoIGEgbmFtZXNwYWNlLiBCZWNhdXNlIG9mIHRoaXMNCiAgICByZXF1aXJl bWVudCwgdGhlcmUgYXJlIG1hbnkgcmVwZWF0ZWQgbmFtZXNwYWNlIHN0cmluZ3MgaW4gdGhlIGlk ZW50aWZpZXJzIG9mDQogICAgdGhlIGl0ZW1zLiBJZiB3ZSBhc3N1bWUgdGhhdCB0aGUgZGVmYXVs dCBzdGFydGluZyBuYW1lc3BhY2UgaXMgdGhlIG1vZHVsZQ0KICAgIGFzc29jaWF0ZWQgd2l0aCB0 aGUgLnNpZCBmaWxlLCB3ZSBtYXkgc2hvcnRlbiB0aGUgLnNpZCBmaWxlPw0KDQogICAgLSBYdWZl bmcNCg0KDQoNCg0K From nobody Wed Mar 31 09:05: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 1ADCF3A2D11 for ; Wed, 31 Mar 2021 09:05:17 -0700 (PDT) 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 LJ5V9XrUPV5t for ; Wed, 31 Mar 2021 09:05:12 -0700 (PDT) Received: from wforward1-smtp.messagingengine.com (wforward1-smtp.messagingengine.com [64.147.123.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F7C3A1850 for ; Wed, 31 Mar 2021 09:05:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 1407F1569; Wed, 31 Mar 2021 12:05:06 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Wed, 31 Mar 2021 12:05:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ePK8ZUPjhnNj6NXWxHl7xGMbdrxizWNDTFAkDrF0p 3I=; b=BTSnXxwSmFyHecSQ2OzBcRrR3D3oOJtXZDqZxwRRmzlcycwciBY94x8wR f/qlI25adYOMC/9oEbMXJiE3N9rGt40KMQLGIIPgCVUMq4AqQ06horiFpOaLyiiw /fzPBogMeZ3Xtxu0AzOolkffRGPOgTtw7pDmfr6t9A6o9B0FYsb0j3Kd8ntmb+mM QbVnraTkf/JGkaSD26e7mbYR1X8NXWlPS4Og7vssX/9amBeWjCQQ2iPNUL+uyfLA dy/siRjnscA0g7TtRqdDhZd7LpNQw+868uCgOaMtYSvuHtu5lGUqK0V8SrgB+y4A Mad0BFhruX+YvdQSzEFE7oAEi03xA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeivddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgr ihhmvggplfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvg hrnhepteffjeffgeevhfeggeffhfeuhfeivdfhfeelfedvtefgfeelhedufffggffgtddu necuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D5415420061; Wed, 31 Mar 2021 12:05:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: In-Reply-To: <4EA9EDD9-0B3F-44E8-A1FC-9D8E5FB392DE@tzi.org> References: <4EA9EDD9-0B3F-44E8-A1FC-9D8E5FB392DE@tzi.org> Date: Wed, 31 Mar 2021 19:04:42 +0300 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: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-palom?= =?utf-8?q?bini-core-oscore-edhoc-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: Wed, 31 Mar 2021 16:05:17 -0000 Dear CoRE, We did issue the WGA for this document with the deadline of March 22.=20= As Carsten already mentioned there was in-room consensus of +9 attendees= .=20 As there has been no opposition and we have a good number of people inte= rested I think we can close the adoption call today and continue this do= cument as a CoRE WG draft.=20 Authors are encouraged to migrate the working document to the CoRE GitHu= b repo. Please ask if you need help with that.=20 Ciao! --=20 Jaime Jim=C3=A9nez On Fri, Mar 12, 2021, at 7:13 PM, Carsten Bormann wrote: > In the Monday CoRE meeting, we had pretty good in-room consensus to > adopt draft-palombini-core-oscore-edhoc as a WG draft (Adoption call: > +9, one "not raise hand" (explaining: not against, but not sure > either), no opposition). >=20 > As usual, we need to confirm this consensus on the list. >=20 > If you are opposed to adopting this document, please speak up on this > list until March 22, close of business. >=20 > (No need to reaffirm consensus if you were in the meeting.) >=20 > Gr=C3=BC=C3=9Fe, Carsten (stand-in WG chair for a few more hours) >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Mar 31 09:08: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 9A3163A2D26 for ; Wed, 31 Mar 2021 09:08:01 -0700 (PDT) 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 w0o2mTr-govk for ; Wed, 31 Mar 2021 09:07:56 -0700 (PDT) Received: from wforward1-smtp.messagingengine.com (wforward1-smtp.messagingengine.com [64.147.123.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A731C3A2D25 for ; Wed, 31 Mar 2021 09:07:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id BDA9613A9 for ; Wed, 31 Mar 2021 12:07:54 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Wed, 31 Mar 2021 12:07:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=5hSKHcxhIaQXKxVePfeK8cLO5aR7vfRsQ8XFnJ9si FM=; b=twEyvx4WgGOfrfAd5RwGDSVqXEj+WRGr9oT9XgbX2ZWEAAq1n3mppWV9A 1ZJm39z7OhcNaZP08WiEuHsSL+ollaBaBpGVDEzjXbJczzYXdr/Ps1vFovIQyMir C7W6RVj3cGt5ARx7lTMVaNa0ffxQkPY6H7DDwKc36O1fjSXMhGqcKCNSa89yiGNt y82GJqJHiVBO9jkt7yfMNrkSeHRuULDf/9nrWORraFjiXEcSE0LGTQ3ILmC0oh/n y15hpshAOEwKjSWi891CrDj2wCVEPsn1RqeiNQAxr3wlMLGheIXgCm3l/nsjryPj hnyqcgTypATtt1KkGd6iJdJ595Hkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeivddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpeflrghimhgvpgflihhmrohnvgiiuceojhgrihhmvges ihhkihdrfhhiqeenucggtffrrghtthgvrhhnpeetffejffegvefhgeegfffhuefhiedvhf efleefvdetgfefleehudffgffggfdtudenucffohhmrghinhepihgvthhfrdhorhhgnecu vehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvg esihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6295F420061; Wed, 31 Mar 2021 12:07:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <4381eb0a-f2ed-4b93-8540-416b4ba8eaa2@www.fastmail.com> In-Reply-To: References: Date: Wed, 31 Mar 2021 19:07:33 +0300 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: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirming_the_adoption_of_draft-t?= =?utf-8?q?iloca-core-observe-multicast-notifications-05_as_a_CoRE_WG_docu?= =?utf-8?q?ment?= 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, 31 Mar 2021 16:08:02 -0000 Dear CoRE, Similar to oscore-edhoc, we issued the WGA for draft-tiloca-core-observe= -multicast-notifications-05 with the deadline of March 22. As Carsten al= ready mentioned there was in-room consensus of +13 of the attendees.=20 As there has been no opposition and we have a good number of people inte= rested I think we can close the adoption call today and continue this do= cument as a CoRE WG draft.=20 Authors are encouraged to migrate the working document to the CoRE GitHu= b repo. Please ask if you need help with that.=20 Ciao! --=20 Jaime Jim=C3=A9nez On Fri, Mar 12, 2021, at 7:15 PM, Carsten Bormann wrote: > In the Monday CoRE meeting, we had very good in-room consensus to > adopt draft-tiloca-core-observe-multicast-notifications as a WG=20 > document (+13 on adopting, no opposition). >=20 > As usual, we need to confirm this consensus on the list. >=20 > If you are opposed to adopting this document, please speak up on this > list until March 22, close of business. >=20 > (No need to reaffirm consensus if you were in the meeting.) >=20 > Gr=C3=BC=C3=9Fe, Carsten (stand-in WG chair for a few more hours) >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Mar 31 10:00: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 DE9CC3A3071; Wed, 31 Mar 2021 10:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham 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 Ht5WZXAjTo5T; Wed, 31 Mar 2021 10:00:18 -0700 (PDT) Received: from wforward1-smtp.messagingengine.com (wforward1-smtp.messagingengine.com [64.147.123.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818823A2EF5; Wed, 31 Mar 2021 09:59:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id AEA201CE0; Wed, 31 Mar 2021 12:59:54 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Wed, 31 Mar 2021 12:59:54 -0400 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=fm2; bh=+ra/nx F55rIoIzVfejogiyEFWusm3m+kO+2I6VOdJ3Y=; b=PZ+DuFwcKICwR1BGZqO/eM qMjC5R2aFBVD8WcC8oUzZAf8rX4zlure2cO88bW1eyIzo9V8rf2ESXBHMVf4LnpO VPnN49wmPQg1lhO1izJ3qglxwUu7BuuyB9AIYTz14YpoHIyDyoQxdSABaxqaNdMz o8KZhrTHjhmlD1jp+vEdNNUNB+2kQ9VUTIqqz+zA5+rRtPwB0732KDTIfhZ9JRtJ F0hmhbFg8ErF0CMVl8hhSSG/Cr2pB+yxlnTqIb2g6Q7mRRDj6en+GBvht/VGHls2 qfqeh9fqvZEHqbK/lmIuiN7PbKuQcNyzJBKjzfv5RFidQqjwisVl0/29bZtZ/cdQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeivddgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqh ertderreejnecuhfhrohhmpeflrghimhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhk ihdrfhhiqeenucggtffrrghtthgvrhhnpefggfejkeelgfeiteehfffftddtgeejffehfe evudetteelgfdvheegfeeltdegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E275E420061; Wed, 31 Mar 2021 12:59:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <84d9517b-5421-42bf-bad7-37c1d625a25f@www.fastmail.com> Date: Wed, 31 Mar 2021 19:59:29 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: draft-ietf-core-senml-versions.authors@ietf.org Cc: core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] IPR Call for draft-ietf-core-senml-versions 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, 31 Mar 2021 17:00:27 -0000 Dear CoRE and SenML Versions authors, We are in WGLC for the draft draft-ietf-core-senml-versions, as part of = the process and before IESG submission the chairs have to solicit knowle= dge of any IPR that may pertain to the work. If there is IPR, it must be disclosed in compliance with IETF IPR rules = (i.e., RFCs 3669, 5378, and 8179). Please indicate if this has been don= e. If you are an author or contributor, you must reply to this email to ind= icate the IPR status. Ciao! --=20 Jaime Jim=C3=A9nez From nobody Wed Mar 31 12:19:53 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 268AF3A334B; Wed, 31 Mar 2021 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yQPtlCYPMO9; Wed, 31 Mar 2021 12:19:46 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574C83A3344; Wed, 31 Mar 2021 12:19:46 -0700 (PDT) Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4F9bjX5GdJzyV2; Wed, 31 Mar 2021 21:19:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <84d9517b-5421-42bf-bad7-37c1d625a25f@www.fastmail.com> Date: Wed, 31 Mar 2021 21:19:44 +0200 Cc: draft-ietf-core-senml-versions.authors@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 638911184.064485-2ebff43f87b2c86e2fedbf5160cbf016 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84d9517b-5421-42bf-bad7-37c1d625a25f@www.fastmail.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] IPR Call for draft-ietf-core-senml-versions 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, 31 Mar 2021 19:19:52 -0000 On 2021-03-31, at 18:59, Jaime Jim=C3=A9nez wrote: >=20 > Dear CoRE and SenML Versions authors, >=20 > We are in WGLC for the draft draft-ietf-core-senml-versions, as part = of the process and before IESG submission the chairs have to solicit = knowledge of any IPR that may pertain to the work. >=20 > If there is IPR, it must be disclosed in compliance with IETF IPR = rules (i.e., RFCs 3669, 5378, and 8179). Please indicate if this has = been done. >=20 > If you are an author or contributor, you must reply to this email to = indicate the IPR status. Hi Jaime, I am not personally aware of any patent claims that would read on this = specification. Gr=C3=BC=C3=9Fe, Carsten