Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt

Marco Tiloca <marco.tiloca@ri.se> Wed, 09 December 2020 16:26 UTC

Return-Path: <marco.tiloca@ri.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB5A3A0EC0; Wed, 9 Dec 2020 08:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, 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=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 UpvkfZeZ88Bi; Wed, 9 Dec 2020 08:26:53 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150084.outbound.protection.outlook.com [40.107.15.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 72F063A0EC4; Wed, 9 Dec 2020 08:26:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EhAM139Eh6y4yEx/DWpK5fVIGIb6QgrNwchoEMRIPIM+be2HmtQ4W+9rPmZjBdnorWVtEBZGWUSJvSCq9/6/Ybh5Z4+cQZ2b0zqo+8H/gHQOURXCi8FuWghWmGt6hWzsgacg/V9n3M5/iwCHoZOayqEiMZ4uTc48ntHhLTlhqISGSSEakZPZ9x/65MvU+44lbQBy0g4wwyrLD5dx8L/VVFOTRvwdGju6AHf/tAXrFlRWqlOqC2tbHBCGQXyEeDDsODlr8BhR9Tx4qGm2TXJO7SIABKWTFXlynDNAlCZhq2CFFN7u9jm6l7T965LUfyjrZ88Q73RbA/Lj84Z23vsjPw==
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=g8cjKVmSi4TjcWHMJ/xiC3MUWFrWawCX6t/tKiyIwRc=; b=dqAy5CoVxQiDCryCp/ZqiFZx77ymzYsanYdF2Dt8geSnZxxsD9jTy32Hw5ztrB7POH6IeP1FcEsrTgwlRwH8DRAAXsIgvFbLozuE9YoJitXT8UQZERgE+hxNR5ohOoMrf5O2J9TymUCKfK9QyCU5Sdm6QktXtRXW6OprIPi1QsUYHqy3rmU0Ap7FQ2uAdLLaKkbSJb/6L+n8I73PLFhvSHKkWG9aH3xKAj4KOKgBBHk2nLpdIdO93DzVUkqzXKNsAiTdg1GU8dW5qDvpOCDj2AtoTEOH4kSjnkisYLxIb+/PhlNAiEkX6IBam0MS7IkBOAKtRmk0zup81J8h2RUdyA==
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=g8cjKVmSi4TjcWHMJ/xiC3MUWFrWawCX6t/tKiyIwRc=; b=Urc9TQWQQXCp1zHl+2frjrvuGqvsgLU7AU/AJZ77s/pjNkXMY/HBUhTk1/8ZML+CjTblfIBhCDgsvu0toUlrdwkrS5WfiIrZ6qfT5NKn5xDYEcpOTf554U8Zg2SR+i/klsOhCdnuLuzBXjIwVj6yxd7gBoSeEwpqSc/rQXQfG/k=
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 DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Wed, 9 Dec 2020 16:26:48 +0000
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3632.023; Wed, 9 Dec 2020 16:26:48 +0000
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, "draft-ietf-ace-oscore-profile@ietf.org" <draft-ietf-ace-oscore-profile@ietf.org>, Ace Wg <ace@ietf.org>
References: <160381525062.27226.4156909974711721360@ietfa.amsl.com> <CADZyTknMd1c0jH-O73HymDCABdTQ4JvOu9zfZQf4Q4aaAo3Wtg@mail.gmail.com> <02a1d3ce-071b-e35a-104f-333e54458d4a@ri.se> <81EAD8CA-2CFD-4295-86B3-44C3B8676A27@ericsson.com>
From: Marco Tiloca <marco.tiloca@ri.se>
Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA==
Message-ID: <06e9b352-567d-5071-009a-670eabbb9390@ri.se>
Date: Wed, 9 Dec 2020 17:26:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
In-Reply-To: <81EAD8CA-2CFD-4295-86B3-44C3B8676A27@ericsson.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KTipmymRcJF3Sr6o85Ru6DCn8SbB5JF7I"
X-Originating-IP: [31.13.191.167]
X-ClientProxiedBy: HE1PR0501CA0026.eurprd05.prod.outlook.com (2603:10a6:3:1a::36) 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.8] (31.13.191.167) by HE1PR0501CA0026.eurprd05.prod.outlook.com (2603:10a6:3:1a::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Wed, 9 Dec 2020 16:26:47 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3c89a925-9f20-43df-74a5-08d89c5f3a1c
X-MS-TrafficTypeDiagnostic: DB8P189MB1032:
X-Microsoft-Antispam-PRVS: <DB8P189MB1032D244E0A178E9BEE1D94B99CC0@DB8P189MB1032.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: pgaVGxKF7f/Kym75g7LO+J3ht43bwvOEgx/4xKG8/dRkqkpbC/Ii0hLGv75xo569BYoqgUY1bX1hkTk4jU9C0wZlNLvGJKVaiUlM577fSS2+KupU3e7w0XPvVzmY9psAooUFAASJITaF4LyYfg3htlHALFF6yrL2eIfydZdTWAtqBlI7EPlCN9UDFznS6SJxwUXl5tX2z5hnfr6ZJlWuF4u73BCF8ZE1tjw8xit7emgq4/IVigD46eI4p+eY9DnzIkhD/QsHYCrDXHGFsSJK4RJOkHCpEzJwm5zJHg8H8qVEHNkw+FjXQ5AYuDVM4xU0nyjK2Ul5K9vnuOzb3Y9fk3flXCTXRy7g3/B5TCFCVGBPKezrv9N40pLObU6C5x5c0AoNJpevimfmxtus+nob3/naaSZSKCvTaYWLGdlowRBdQhcsnJA6GTqtKIGmENyzQQ+xZK131cQ8ks8YZg7G7IEazr7IsIzjIA7++KksDPbhRnVO0kmj2jaqq7K/nq7nosIenltgUuWj6lL0Q38xEg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(346002)(6486002)(166002)(26005)(8676002)(36756003)(66574015)(83380400001)(235185007)(30864003)(31686004)(956004)(966005)(52116002)(110136005)(16576012)(34490700003)(2616005)(2906002)(66556008)(4001150100001)(186003)(5660300002)(21480400003)(53546011)(45080400002)(508600001)(66476007)(31696002)(44832011)(8936002)(16526019)(33964004)(66946007)(86362001)(45980500001)(43740500002)(579004)(559001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TkRuZFA0NE1zWmRHZjh3dTQrTW9DT0RtTklZbzUyamlKbXBjSHFBOE9TQ0Fx?= =?utf-8?B?NzFnOGxsQzY5Q0xsMWtBcXpWQ1hpZWNHSG1hWjlkSzNrcEJuc05DaTFodDBS?= =?utf-8?B?SUVkamRHTE0xYjNBYkwwcU4wcERIQkpXeHo5Q244NDRiWHQvRzRHL2NvdnMz?= =?utf-8?B?MEtFWnZ6YmtlN3NtTjB6QWQ1cktKZ1JzOVh0bnpCWnlxNjJSKzZKRmh2TUtT?= =?utf-8?B?RVV1TEZVTXcxcld6V0hWTWRXWUhjcExlSy9tWXYrTEpENENDZm5nbmtSUXVy?= =?utf-8?B?ZjgwdkkvaG1peFpuM2hBUFJaSHV4WmJRclpuRHMrZmJUcXNseDE3WHl1N09R?= =?utf-8?B?TCtKZlU3WUNTT29pSVRkVnZneWsxWUZBdFlidFBGSi9ISTV4NzZvYm01OEVL?= =?utf-8?B?bjc1V1Q1eGxMdmNwaEZNMkJFaFg5R2VLQ09ta1JHcEJkd2NNYjh2WkxoSlV1?= =?utf-8?B?d1FGb0s0MjZoMHJ5eUMyRHR6SmQ2MHMvVmVhd2c4NFArcFRrYmh6NXNxeTBL?= =?utf-8?B?aWNONVNZczZQRE9FNVlBQTNSQnJoOUpxNGIvZDJldUdHdEJyelRuQk4rRUFx?= =?utf-8?B?THZuYW9iK3dHRzNNTUdiZm0xVFdFTEpKKzA0SVFJUzE2QXk0c2lpa2M0N2JN?= =?utf-8?B?SjR3N2JBa0pFZjFIOGx6KzVIMjBuWEpGbW9NMWNWWGd5WWdWV1A0ZFFGQ2Z0?= =?utf-8?B?N3RkdXBVZ3FQY3NKN212UHJ0OGI1cGc3RlhGVzkrVlNkNFpCQXR3Y0ljV3ky?= =?utf-8?B?UmtIbHZoZzhnak5SUlIwajVSR1F3Y2plMi9zWWVNdG5jS2NWVjN1TUpwQWFq?= =?utf-8?B?ZlpIenlEQVZma1VIKzRhM3VQK0h4dU00TklGSHhXVmlQem8xN2dObk9GSjBC?= =?utf-8?B?Yi9RTG5QYW9ZTFJNNUpWM1dTNG5uakJsVU5YMnVaM0JOYkRUeTdlYytKdDFk?= =?utf-8?B?eEMxbmJUMXpQYUtqTFJiajM3N1hoeHptQWZtcFdhazRMVEhQb2lpMk5WVTFU?= =?utf-8?B?UWhwUHhtWkNGbmp5SkpmNTFKSDZpWlEyNFMwZ25USFBSMWtLemcvNlYwOExS?= =?utf-8?B?UXF0enJOYTM1clhwUVdXVlRiUVQ5czNMYVF2V295VmppR0VHaW9BZkw0c0dy?= =?utf-8?B?RVRJM0tUZUpXM0RaK3Bwbjh3djlidnZ4bE4rNDJ4RlFkVUJSVCsvb3loVi9k?= =?utf-8?B?MDZjQld3NWM5aytkMDdZK1NWM2J4VjJ2QmtYUzRRNzZUUWlHV1NVL2VGd0sr?= =?utf-8?B?WnRtYjdWb2IwUWl6cDFOM290T0drT3BNb1BYOHFmSDRQSHNaRG82UjJFaG5v?= =?utf-8?Q?pDPhO5gf0vdRwsJe7dVd5Yl7yOrnbaXDwU?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2020 16:26:48.2510 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c89a925-9f20-43df-74a5-08d89c5f3a1c
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IEMnDrSlNOnxaMDhy3CxV/6HE6t2xs6uWUBHjS2i7HOtGQ2PwwVtbcnHQydIKOpBcS2JUJ4EZLIsLZMo0NvzNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1032
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/s6fPWfD3ClicmOgcQ-B4KFRZ4_0>
Subject: Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 16:26:59 -0000

Hi Francesca,

Thank you for taking care of the review! I think the commits in the PR
address all my comments.

Best,
/Marco

On 2020-12-08 16:42, Francesca Palombini wrote:
>
> Hi Marco,
>
>  
>
> Thanks, very helpful as always! I have implemented all the comments in
> this PR https://github.com/ace-wg/ace-oscore-profile/pull/44
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fpull%2F44&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720883194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UPQbvAjheecQ3qFTNZrfA%2F2rXtocuc5U5AQdvhFxxNI%3D&reserved=0>
> , if you give me the OK I can merge and upload a new submission. Happy
> to see that the comments were about clarifications and editorials.
>
>  
>
> Inline detailed answers.
>
>  
>
> Thanks again!
> Francesca
>
>  
>
> *From: *Marco Tiloca <marco.tiloca@ri.se>
> *Date: *Thursday, 19 November 2020 at 17:04
> *To: *<draft-ietf-ace-oscore-profile@ietf.org>rg>, Ace Wg <ace@ietf.org>
> *Subject: *Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt
> *Resent from: *<alias-bounces@ietf.org>
> *Resent to: *Francesca Palombini <francesca.palombini@ericsson.com>om>,
> <ludwig.seitz@combitech.se>se>, Göran Selander
> <goran.selander@ericsson.com>om>, <martin.gunnarsson@ri.se>
> *Resent date: *Thu, 19 Nov 2020 08:03:54 -0800 (PST)
>
>  
>
> Hello OSCORE profile authors and ACE,
>
> Please, find below some WGLC comments. Hope it helps!
>
> Best,
> /Marco
>
>
>
> Section 1
>
>  
>
> * s/is not done by a/is not achieved through a
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/after the first OSCORE exchange/after the first message exchange
>
> using OSCORE
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 2
>
>  
>
> * "This specific identifier, encoded as a byte string, is assigned by
>
> the AS to be unique in the sets of its OSCORE Security Contexts ..."
>
>  
>
>    To avoid confusion, it's probably better to say "unique among the
>
> issued sets of OSCORE input material", since the AS can have actual
>
> OSCORE Security Contexts it uses to communicate with Clients or Resource
>
> Servers.
>
>  
>
> FP: Ok, fixed. Replaced with OSCORE security input materials
>
>  
>
> * Referring to 'id' as specific identifier, the text says: "and is not
>
> used as input material to derive the full OSCORE Security Context."
>
>  
>
>    That's correct, but then the identifier is later included in Table 1
>
> "OSCORE_Input_Material Parameters" :-)
>
>  
>
>    Perhaps it's fine to just revert to OSCORE_Security_Context_Object,
>
> both for the name of Table 1 and in different spots of the text? They
>
> would still consider 'id' as OSCORE Input Material Identifier, while
>
> aligned with the registry name from Section 9.4.
>
>  
>
> FP: I see your point, but the name was source of discussion before and
> I'd rather not go back on that. I don't think it is a problem that the
> 'id' is both part of the "OSCORE_Input_Material" object and also not
> part of the actual input material. After all it needs to be part of
> the object to identify it. What I did is to change its CBOR label
> though, to have it as 0, since I think that makes more sense that to
> be in the middle of other input materials. Note that this is a change
> that will affect implementations.
>
>  
>
> * s/If the request verifies/If the request is successfully verified
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/until token expiration/until token deletion, due to e.g. expiration
>
> or revocation
>
>  
>
> FP: thanks for this comment. I did only keep expiration as example,
>
>  
>
> * s/the same or different/the same or a different one
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * Figure 1 can also show the achievement of mutual authentication,
>
> following the OSCORE exchange at the end
>
>  
>
> FP: Good point, added.
>
>  
>
>  
>
> Section 3.1
>
>  
>
> * s/object. kid field carrying/object, with the kid field carrying
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 3.2
>
>  
>
> * "... profile negotiation can be omitted" - I think "profile signaling"
>
> better reflects what may happen here, see also the beginning of the
>
> paragraph.
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/in the the/in the
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 3.2.1
>
>  
>
> * In the text entries following Table 1, the CBOR integer labels need to
>
> be aligned with the CDDL summary at the end of the section.
>
>  
>
> FP: I think it was? Now I moved id to index 0, so I switched the order
> there too.
>
>  
>
> * s/This parameter identifies the OSCORE_Input_Material/This parameter
>
> identifies the OSCORE_Input_Material object
>
>  
>
> FP: I will let the RFC editors decide on that one :) Don't want to
> become too verbose if it's not needed.
>
>  
>
> * s/the "id" type is byte string/the "id" type is bstr
>
>  
>
> FP: ah, good point. I actually changed all the description to extend
> the type (so byte string instead of bstr, etc), in order not to use
> CDDL in text.
>
>  
>
> * This version -13 has removed 'clientId' and 'serverId' from Table 1
>
> and thus as code points from the "OSCORE Security Context Parameters"
>
> registry.
>
>  
>
>   No strong need to include them back, but even if this profile does not
>
> use them and does not send them on the wire, I think they still belong
>
> to the same namespace, since they are descriptive of a security context
>
> and are in fact also used as input material to derive it :-)
>
> FP: I agree with that, and think the first draft to use them will
> register them. The registration of the OSCORE_Input_Material does not
> specify how this material is used, that is up to the draft describing
> the derivation process, so it does not make sense to register them
> here without explaining the derivation process using those parameters.
>
>  
>
> Section 4
>
>  
>
> * s/the RS and client authenticates themselves/the RS and client
>
> authenticate each other
>
>  
>
> FP: Ok, fixed.
>
> * s/successfully verified the response from the RS/successfully verified
>
> a response from the RS as protected with the established OSCORE context
>
>  
>
>    (similar occurrences are also later in the text)
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 4.1
>
>  
>
> * In the first paragraph, I suggest to rephrase as "and the posted
>
> access token is still retained".
>
>  
>
>   That doesn't require to explicitly mention "valid", since asserting
>
> especially validity can be non-trivial for the client, e.g. in case of
>
> Token revocation.
>
>   (similar occurrences are also later in the text)
>
>  
>
> FP: I am not sure about this one: I don't think talking about
> "retaining" an access token is precise enough (a token might be
> "retained" in memory, but expired). "Valid" to me seems less
> ambiguous. I would expect implementations to have a way to mark token
> as valid or non valid (e.g. if expired or revoked). What woud be
> difficult for implementations to assert validity?
>
> * In the second paragraph, I suggest to extend the ending as:
>
>  
>
>   "... makes sure that it does not collide with any of its Recipient IDs
>
> currently used. These include also Recipient IDs used as ID1 value for
>
> ongoing executions of this profile."
>
>  
>
> FP: Good point, I think I got it. Rephrased it with " nor with any
> other identifier ID1 if the client is executing this exchange with a
> different RS at the same time."
>
> * s/the client MUST wrap the token and N1 in a CBOR map/the client MUST
>
> wrap the token, N1 and ID1 in a CBOR map
>
> FP: Ok, fixed.
>
>  
>
> * s/using the "access_token" parameter/using the 'access_token' parameter
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * In the sixth paragraph, the last sentence says "... as different
>
> nonces will be used." Doesn't the client and the RS also negotiate new
>
> IDs like they did in the first posting of the same original token?
>
>  
>
> FP: yes, but the client might decide to reuse the same ID, I don't
> really see a problem with that.
>
>  
>
> * In the last paragraph: "The client MUST only send the access token in
>
> the payload, no nonce or identifier are sent."
>
>  
>
>    Just to be sure, can you expand on this request format? I suppose the
>
> client still uses Content-Format "application/ace+cbor", just including
>
> only the 'access_token' entry in the map. Correct?
>
>  
>
> FP: Yes that is correct. The request is the same as in Figure 10 with
> the exception that it is protected with OSCORE and that no nonce nor
> ids are sent.
>
>  
>
> * In the last paragraph: "... the RS will replace the old token with the
>
> new one, maintaining the same Security Context."
>
>  
>
>    This replacement step can be expanded for clarity. A simple 1-to-1
>
> replacement would overwrite also the stored 'cnf' claim from the
>
> original token, among other things. So it should be more about
>
> selectively replacing some information originally coming the first
>
> token, while keeping some other from it. What to actually replace should
>
> include, for instance, information related to access rights (e.g.
>
> scope), and to the new token's lifetime (exp, exi).
>
>  
>
> FP: I believe what you were commenting here (i.e. the RS behavior) is
> actually described in details in section 4.2, starting with "If the RS
> receives the token in a OSCORE protected message...". I only want to
> give the intuition here, focusing more on the client without go into
> the details of what the RS has to do as a consequence, which is why I
> am tempted to not make a change here. But if you think something is
> missing from 4.2, let me know and I'll see if we can expand there.
>
> * While reading this, I was wondering if one could repost the same first
>
> token to rekey the OSCORE context. This is mentioned at the end of
>
> Section 4.3, but anticipating the possibility here and adding a forward
>
> pointer to Section 4.3 would help.
>
>  
>
> FP: I added a paragraph in section 4.1 (starting with "The client may
> also chose to re-POST the access token...")
>
>  
>
> Section 4.1.1 and Section 4.1.2
>
>  
>
> * The first sentence captures the case where the first token is posted
>
> or re-posted. It can be rephrased to cover also the posting of a token
>
> for updating access rights, where these parameters are not included.
>
>  
>
> FP: Ok, added text at the end of the sentence.
>
>  
>
> Section 4.2
>
>  
>
> * "any of the mandatory    parameters from the AS or the identifier) ..."
>
>  
>
>    It's worth making it explicit that the mentioned identifier is 'id'.
>
>  
>
> FP: I actually meant the identifier id1. Added it.
>
>  
>
> * s/in the 'osc'/in the 'osc' field
>
>  
>
> FP: Ok, done.
>
>  
>
> * "... the RS must respond" --- Should this not be a MUST ?
>
>  
>
> FP: No, this requirement comes from the framework, so it is non
> normative (the normative one is "The RS MUST follow the procedures
> defined in section 5.8.1 of
>
>    [I-D.ietf-ace-oauth-authz]")
>
> * s/is different from the ace_client_recipientid/is different from the
>
> value specified in the received 'ace_client_recipientid' parameter
>
>  
>
> FP: Ok, done.
>
>  
>
> * Second paragraph after Figure 11
>
>  
>
>    - s/MUST discard/MUST ignore
>
>  
>
> FP: Ok, done.
>
>  
>
>    - s/the "cnf" parameter of/the 'cnf' claim of
>
>  
>
> FP: Ok, done.
>
>  
>
>    - s/matches the OSCORE Input/matches with the identifier of the
>
> OSCORE Input
>
>  
>
> FP: Ok, done.
>
>  
>
>    - Related to a previous comment about token replacement, some
>
> information has to be retained from the first token, as not present in
>
> the new one.
>
>  
>
> FP: I am not sure how to implement this comment without making it very
> hard to read. I trust readers at this point will understand what
> "discard the old token and associate the new token" means.
>
>  
>
>    -s/in the "cnf" parameter/in the 'cnf' claim
>
>  
>
> FP: Ok, done.
>
>  
>
> * It can happen that all is fine for the RS, it installs the OSCORE
>
> Security Context, it responds to the client, and the response gets lost.
>
> In this case:
>
>  
>
>    - After a timeout expiration, can the client simply repost the same
>
> token as mentioned at the end of Section 4.3? This can be another reason
>
> for reposting the original token, to mention in the sixth paragraph of
>
> Section 4.1.
>
>  
>
> FP: Yes, added.
>
>  
>
>    - Should the server delete the token and the OSCORE Security Context,
>
> if not receiving an OSCORE protected request from the client before a
>
> timeout expires? After all, it's reasonable to assume that a client
>
> sends a request right away or not long after the token post is
>
> completed. If this is included, it would be one more point in the bullet
>
> list for the RS in Section 6.
>
>  
>
> FP: It is reasonable, however I don't want to add it to Section 6 as I
> don't want to make it a requirement to the RS. It is up to
> applications to define policies for such a timeout. We make it clear
> that it's only after the first OSCORE exchange has happened that C and
> RS are assure that the exchange succeeded. How long to wait, I think
> should be out of scope.
>
>  
>
> Section 4.2.1 and 4.2.2
>
>  
>
> * The first sentence captures the case where the first token is posted
>
> or re-posted. It can be rephrased to cover also the posting of a token
>
> for updating access rights, where these parameters are not included.
>
>  
>
> FP: Ok, done
>
>  
>
> Section 4.3
>
>  
>
> * s/Secret from the parameter, received/Secret from the parameter received
>
>  
>
> FP: Ok, done
>
>  
>
> * If the client stops the exchange, it should also unlock the ID1 value
>
> previously offered.
>
>  
>
> FP: I believe this is implementation details. I think this should be
> covered by the clarifications above.
>
>  
>
> * s/to RS/to the RS
>
>  
>
> FP: Ok, done
>
>  
>
> * The end of the last paragraph mentions possibly reposting the same
>
> first token to rekey the OSCORE context. Consistently with the fourth
>
> paragraph of Section 4, I suggest to mention here again that this
>
> request is not protected, since not related to updating access rights.
>
>  
>
> FP: Ok, done
>
>  
>
> Section 5
>
>  
>
> * s/profile, other/profile, but other
>
>  
>
> FP: s/,/; instead, but done
>
>  
>
> Section 6
>
>  
>
> * s/context expires/context expires or is revoked   (2 instances)
>
>  
>
> FP: Again, I am hesitant to add revoked here, as the framework barely
> touches on revocations of tokens, and explicitely states that
> expiration is the norm instead.
>
>  
>
> * In the fourth bullet point, isn't this actually fine if the reposted
>
> token is exactly the original first token? In that case, new nonces (and
>
> I guess also IDs) are exchanged.
>
>  
>
> FP: This is fine, but it means the RS is wishing to re-derive a new
> context, so the old one must be discarded.
>
>  
>
> * I think there should be one more bullet point in the client list, for
>
> when the client receives back ID2 == ID1 from the RS, after having
>
> reposted the original first access token.
>
>  
>
> (This relates to a previous comment for Section 4.1; I thought a
>
> reposting of the first original token involves an exchange of new nonces
>
> as well as of new IDs)
>
>  
>
> FP: Why? I don't understand why this is not already covered. Ah ok so
> maybe this is not valid anymore?
>
>  
>
> Section 7
>
>  
>
> * s/usecase/use case
>
>  
>
> FP: Ok, done
>
>  
>
> * s/for a client/for a same client   (2 instances)
>
>  
>
> FP: Ok, done (I am sure the RFCEditor will change this to something
> else too :) )
>
>  
>
> * I think it's better to expand C and Cs to "client" and "clients"
>
>  
>
> FP: Ok, done
>
>  
>
> On 2020-11-08 23:51, Daniel Migault wrote:
>
>     Hi, 
>
>      
>
>     This email starts a WGLC for the draft
>     draft-ietf-ace-oscore-profile until Monday November 23. We would
>     like to send the document back to the IESG with sufficient
>     confidence, so please take the time to review it carefully provide
>     comments and feed backs.
>
>     Note that also that the document (13) is being reviewed by the
>     security directorate.
>
>      
>
>     Yours, 
>     Daniel   
>
>
>     [1]
>     https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D561b951b-0980ac2a-561bd580-86e2237f51fb-7e8ff0f2b460277b%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-ietf-ace-oscore-profile%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980974848%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DDCzcOuQ7MnBLs0hxiHbIAi%25252B1VjBHLBJRzi4N8P9VDV4%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720893147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qok50i4u7VVFEl1OFeUXLRKDiGgpbk4dLbpvkU6Bei4%3D&reserved=0>
>
>      
>
>     ---------- Forwarded message ---------
>     From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>     Date: Tue, Oct 27, 2020 at 12:14 PM
>     Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-13.txt
>     To: <i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
>     Cc: <ace@ietf.org <mailto:ace@ietf.org>>
>
>
>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>     This draft is a work item of the Authentication and Authorization
>     for Constrained Environments WG of the IETF.
>
>             Title           : OSCORE Profile of the Authentication and
>     Authorization for Constrained Environments Framework
>             Authors         : Francesca Palombini
>                               Ludwig Seitz
>                               Göran Selander
>                               Martin Gunnarsson
>             Filename        : draft-ietf-ace-oscore-profile-13.txt
>             Pages           : 32
>             Date            : 2020-10-27
>
>     Abstract:
>        This memo specifies a profile for the Authentication and
>        Authorization for Constrained Environments (ACE) framework.  It
>        utilizes Object Security for Constrained RESTful Environments
>        (OSCORE) to provide communication security and proof-of-possession
>        for a key owned by the client and bound to an OAuth 2.0 access
>     token.
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D577dc830-08e6f101-577d88ab-86e2237f51fb-0882f337db2a5b4a%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-ietf-ace-oscore-profile%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980974848%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DDCzcOuQ7MnBLs0hxiHbIAi%25252B1VjBHLBJRzi4N8P9VDV4%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720893147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zruCrjBZvRmdiFa4COi2psW7iHU4V63fVCOxILxDSyk%3D&reserved=0>
>
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D76148db7-298fb486-7614cd2c-86e2237f51fb-6db7a86c1af38e00%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Ftools.ietf.org%25252Fhtml%25252Fdraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980984842%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DOaxJICL6Bp%25252Fzt5DMwUWcv04yU07JkvEILCNy17Moqro%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720903105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hp433XpyJUn9JsGQChpyoRYt4cJfZJ38YcBps34MEWc%3D&reserved=0>
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D6a06d0a5-359de994-6a06903e-86e2237f51fb-61db490b8c9907fa%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fhtml%25252Fdraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980984842%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253D7Ac6UdrbH6IBIcm2%25252BYWd4iwufwIblv76Nq4VretJZuw%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720903105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m3u076VCs%2FiJaJhjlmeJ7TU6wD0pmnt5gqOvx092rZY%3D&reserved=0>
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D71594c3d-2ec2750c-71590ca6-86e2237f51fb-f0c9e033402ad200%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Frfcdiff%25253Furl2%25253Ddraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980994840%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DR%25252Bj8cmPnyb8DUEcygCzhOpCJBqQbS8gDalwSsVZtdkw%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720913129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F8QwAqDXoF0BILw9dlX81bR1mf5A%2FEnqzxPu%2FIYtGWM%3D&reserved=0>
>
>
>     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
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dca0c6a74-95975345-ca0c2aef-86e2237f51fb-f8b34619f6d31a0a%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttp%25253A%25252F%25252Ftools.ietf.org%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980994840%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253Dpec0ClOMPHj%25252BsHa%25252ByDBFOvDj90aPwlcEURCcQI6igxI%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720923031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UpddxCFd%2B31znTW3iXzzX2xacrnj6GRnHhJher5nX3E%3D&reserved=0>.
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dec181a40-b3832371-ec185adb-86e2237f51fb-0c8012effe9f8cf8%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dftp%25253A%25252F%25252Fftp.ietf.org%25252Finternet-drafts%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981004834%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DAJhNeMUrwuGWnKk7Oazo4jFxm0gX1t7hMcI9IvRIQCk%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720923031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RCz5%2FveS9uLDPSZ3vKyXGniIfA%2Bled5V4tVIZ8lihQY%3D&reserved=0>
>
>
>     _______________________________________________
>     Ace mailing list
>     Ace@ietf.org <mailto:Ace@ietf.org>
>     https://www.ietf.org/mailman/listinfo/ace
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D8c63f3f8-d3f8cac9-8c63b363-86e2237f51fb-12f198f7f4eaea38%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Face%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981004834%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DwMdtJRfiWur2dXXZw8z84usAX7P9vHcvhGy%25252BPNHeDVg%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720932989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BSo5ma5lttya0kAzk8VDD9KHRlptjqENzbl%2FSyVf9xM%3D&reserved=0>
>
>
>      
>
>     -- 
>
>     Daniel Migault
>
>     Ericsson
>
>
>
>     _______________________________________________
>
>     Ace mailing list
>
>     Ace@ietf.org <mailto:Ace@ietf.org>
>
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981024818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1b3a6707-44a15e36-1b3a279c-86e2237f51fb-a3272a3cd4614bf8%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Face%2526amp%253Bdata%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981024818%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526amp%253Bsdata%253DSlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%25253D%2526amp%253Breserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720932989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qtS%2BkSgOGR5xYUBZJzmjz4uRcoTaPvsOOkwqYWwvFMs%3D&reserved=0>
>
>
>
> -- 
> Marco Tiloca
> Ph.D., Senior Researcher
>  
> RISE Research Institutes of Sweden
> Division ICT
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
>  
> Phone: +46 (0)70 60 46 501
> https://www.ri.se <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1ed65bc0-414d62f1-1ed61b5b-86e2237f51fb-af23a91f66f28bf9%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Fwww.ri.se%252F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720942944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Zqn8Rl0IDx8BQ%2BgAeZ9t8%2BQYkSVkdg3qqtnWWo7kla8%3D&reserved=0>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720972812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=rr8CAJby1Nbe7VD2Hyl%2FxhrfQ8wU4SwB21y%2B06NdP2U%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se