Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 30 November 2020 17:30 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2643A0F2F for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 09:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=wDpRLQD+; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=wDpRLQD+
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 WcBK8xf24LhY for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 09:30:22 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10048.outbound.protection.outlook.com [40.107.1.48]) (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 EFD863A0F74 for <rats@ietf.org>; Mon, 30 Nov 2020 09:30:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LoUoDHIW1WfGHb7iDT8Bl8AsVbOlGltYd25BMnMN01I=; b=wDpRLQD+7tUXj0wXlrOc+fMct+u0H42O5PI+qVJUxTDdhE+XttBnss6lSpx+uO2O0nPB1DGsqEzU7hTsf4iCUFftc6Zvmw5J35u/FjZNlZKfsMtqZD/DOWn1NY9pHQztKl724qcLTFkARyCpVxXDBzXvglTaZL4SrYxT+G3XPQg=
Received: from DB6PR1001CA0007.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::17) by DBBPR08MB6139.eurprd08.prod.outlook.com (2603:10a6:10:200::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22; Mon, 30 Nov 2020 17:30:19 +0000
Received: from DB5EUR03FT061.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b7:cafe::c4) by DB6PR1001CA0007.outlook.office365.com (2603:10a6:4:b7::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20 via Frontend Transport; Mon, 30 Nov 2020 17:30:19 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT061.mail.protection.outlook.com (10.152.21.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.26 via Frontend Transport; Mon, 30 Nov 2020 17:30:19 +0000
Received: ("Tessian outbound 13ed5f5344c0:v71"); Mon, 30 Nov 2020 17:30:19 +0000
X-CR-MTA-TID: 64aa7808
Received: from 4e5663b38fb5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 42492C70-8DF8-400D-A791-7B19549CA203.1; Mon, 30 Nov 2020 17:30:14 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4e5663b38fb5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 30 Nov 2020 17:30:14 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QT8VaiBZ4RrR24R10AWq1e7IAiwHINUnHBUBVBPOLhIS2Xr+Zk8bgBcsHSTv6MAViuSpddRAHaT3rs9CDlZH6mZJ23lv2dnQo3mKaCUD30biwLaIi8JAbi2+HjbWgHY5GPqin/vM4zE2h4OG3BziyOqEFnTpj0eF9JfFcJTiQBwWNx025hKsGhF3wjyAwak5rIGCqVZIegTpTMF59MG20tV5Un0I3c2Sdju7Xqk9A2Dw4YcV2OC1xlDq9Z9UUxH+Oo+AUvEnaTb0pjSNIqQ++5Lck891P1VwDKOHX/1PFtl59k55N7QwNOpU0kSumN7OhwqKOA23lp8tpsaHgMlu9g==
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=LoUoDHIW1WfGHb7iDT8Bl8AsVbOlGltYd25BMnMN01I=; b=G7LrwTYljEuub3oBpNJirAaKLor1MHj2ry0AN7CMsK34bzPox2GS5FvpCBhbahm2/ttMbDnAxX6YBP5ZDi9/fbKUlir1z7i6Sa8sMqVPQHK4xM7KcfIB9TWUxjmpLO9RriyuIr6OpiQzO7zbGeGb8tmr/uNYn4Gvvs8E8NGpw723gicXYpzJMh0Fn/oHal5g+/366hv/x311GhwTtpeiQq5gIunFa1cQx68GuVYW2LsBjUHoSHfTLS+yiwXF+Bffsl4jk6UQpgHabRCCbwGRDpp8au3p9rqQjz1q+e6ZCrNO0Q4qenmPFVjDUDUZT3DzldKG7kPDWNd27zD8f8msrA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LoUoDHIW1WfGHb7iDT8Bl8AsVbOlGltYd25BMnMN01I=; b=wDpRLQD+7tUXj0wXlrOc+fMct+u0H42O5PI+qVJUxTDdhE+XttBnss6lSpx+uO2O0nPB1DGsqEzU7hTsf4iCUFftc6Zvmw5J35u/FjZNlZKfsMtqZD/DOWn1NY9pHQztKl724qcLTFkARyCpVxXDBzXvglTaZL4SrYxT+G3XPQg=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3107.eurprd08.prod.outlook.com (2603:10a6:208:60::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.21; Mon, 30 Nov 2020 17:30:13 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 17:30:13 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Giri Mandyam <mandyam@qti.qualcomm.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
Thread-Index: AQHWxozX+iZ16pOalkWO5saguRJyBKng7NuAgAACmzA=
Date: Mon, 30 Nov 2020 17:30:13 +0000
Message-ID: <AM0PR08MB371606D3753BED36E71A5754FAF50@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <24519.1606681083@localhost> <BL0PR11MB312296BEFD428C6D9CE9A5DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB312296BEFD428C6D9CE9A5DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: F43E5C5942B76E4C809E33DEAA29C64E.0
x-checkrecipientchecked: true
Authentication-Results-Original: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=arm.com;
x-originating-ip: [80.92.118.246]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 1c35fa97-cd2f-49e3-f622-08d895559bd7
x-ms-traffictypediagnostic: AM0PR08MB3107:|DBBPR08MB6139:
X-Microsoft-Antispam-PRVS: <DBBPR08MB6139A52627FC8FE8B21C50FAFAF50@DBBPR08MB6139.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:4941;OLM:7219;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: FUHVgU4p14C7O54NdgWjYnSAnNjDEIXa5u9yl4a1AkJ8wWHa5Qsn3rAKhZrOLwNz8PEH/h4T7ArJ64MJLpDhCJQTfui7MVlo5T5LdzvcGlQn651GASS9hy5qnlVqESk8BL+DAev1+hNQ9rISAbM38S2NDVdJtOfYbw8H7PTY9dN045pfd1Y+d03W/CJ7+iIUVOV31itN9RU4YR6gBtPIhBPCQiog6y2AHQ7tCim9Nurlml6iCooD3mJi9PLOw03JM+eKYgnop5exm7RtUz6QpvvOGzzdpZvAdyxUolt9nkrYppIpYGq8bOmfuXL7YV98NgqdpgBnet6K+E+WPURVkAvGCMegcC20zuJP3xdzQsfWcIs8naS+1VNBl6hYdLI6ne8GwGwpLO+KH/d/wVanKA==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(136003)(346002)(396003)(366004)(33656002)(6506007)(186003)(110136005)(4326008)(966005)(53546011)(26005)(76116006)(86362001)(9686003)(316002)(66556008)(2906002)(7696005)(8676002)(8936002)(71200400001)(66574015)(66476007)(478600001)(66946007)(5660300002)(66446008)(52536014)(55016002)(64756008)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?K1lsWW1RWHozdncvMzBpZ1hrRTNkS29NWm9iRk1zRDlnaDBWR3lOc1VCWkJy?= =?utf-8?B?blBXNlUvZnpVVktXQ1lGMkgrY1BveHFGMHBkZEFZbnBENDBiTTk3aFI0US9t?= =?utf-8?B?SUNKMFZHTEJBZlhFRmhQb0V2WEZNU0VENjVxU2c2NVVTWUFYV2NyV3ZGRUtw?= =?utf-8?B?SXZqQzE4QktVVjlEZi9rUW9Cc08xdVJEMHdMaWdmbEw5a09JQ2dsdy96aE9x?= =?utf-8?B?bkl4WU14ZlcxK24rZG5mNzBuMlZtdk9qa1lWa1dEdCtPRG93bmdLckJMczN0?= =?utf-8?B?cHNNeTJPV1c4T3pUMWwwTG1WN3ZoQlJGUWt3Q0MwaVFiYThaWWVLMXdsSXhq?= =?utf-8?B?TzA5MSt0WkJMcnZiMkhEZ0hmaVlUL1RCSUdwSEVwUXpXQ29DK25lTTBMeDRI?= =?utf-8?B?V2ZxMHZXa1pJL3hEVVpnWmJLYlVTMldpTEFQVlA4TWsxeGlIQUQ1TkxuaGtM?= =?utf-8?B?SnBSWWRCUXFMMHlONkZyNHFkWWdGVDNiVWRuTDBpN2xhRDlXbnphL1pISkxX?= =?utf-8?B?RStGWlh1WkFrSDhwVjBMLzNvM3dNMldVT3I4RVk2c1hZTm5pOGZQUU9qa1VR?= =?utf-8?B?WTAxY0JSMXpJTlRoVUNSZGlPUlFqQVlhWlZMbk5JRzdSRUdWMGVjRXFBcHhi?= =?utf-8?B?T1V0cEdBSjU2OTVhYk5Ia3FoV3U4aVpPODRxcklyTjgwWTVOQXhBNGoxSGxX?= =?utf-8?B?ZmhwUDcya3lScDRLVlZCckU3NU8rbEc4SDVONUQwWHh2bHUyenF6QWZ5RitC?= =?utf-8?B?T0pYWlkrWGxKWDJUdE1jL3p5MkFXS1FTZjc3YTJZU2UrRnZaV2h1czVMbVFt?= =?utf-8?B?dUF5eDk2S0pjT0dVT0dSQi8zK0RNUEhHNEkvR3ZCRnE1a1ZKc1o2UzdrNkVD?= =?utf-8?B?Vloyb2N5dmZhS3pzcmdjWHFPM0xaUlczOG9kRCtnL3JtR04yTEZSSkk4OE85?= =?utf-8?B?U3k4Zzl1a2VoaVJMUDNlRzJUbFNmVlg0MFFndWlJcUViWnMvOUZudFdmNklF?= =?utf-8?B?N0xyWExIN3UxNGg0V0tPeFM0MmhCR0ppNlQ2UDFuTjFIZXNoRWlmalRLZXVo?= =?utf-8?B?RUsxL2pCSDMraVlOblNRd3Q5OHMyQk50QlN1MG9oY2ExL0FxVGh4YWxBNmRa?= =?utf-8?B?THBPNWdNQkMrNVE0RVVrN0JybDh4aVNhSUkxNHhlMWVnVnlUckpZa1NmVkx1?= =?utf-8?B?N0NHSmFVdGk5MXBXRkNvTUhSRnNvSENkcm5PMDRDbFRESTQyMXhVb2d5S1pq?= =?utf-8?B?L1RLSk83ZkozWVRaR0hsNE1GODRzb0VVbFhsVzB5eDhFc1hnNDBIVGsxOGVi?= =?utf-8?Q?Avl/IcBwxdle0=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3107
Original-Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT061.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 36d80d38-404c-433f-45cf-08d895559837
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: AhKA9pprKUMSY+GIUsBaBDfbMdLXvo9hT8xEXFs+xSqoQRaaag13+uoGya2gNRq0GKDQrrgEqGWgm798w0BQjJk3rbLWDWAXYLC7/X2Hv+luPbtaEwhIZ3LKMJHC18S+XFTcj18sqlefVI1Vftmopu8umVq2Q2haBUEQE6zsCbQ+3KrCdbHMTGOfji/QdMU04tyj3k3t8tKLowpGCBXKaa6if4iS6wHq6iSNOUM481/o+fp1UMoEw+HEcHZPV/bcC55umw/iKVakEejzrwffwP1PB1pKQna57XHLwKmCb549lducJozsUwq5VGf1u37PrjHCOjFLd1LOyhhUClCd5+cviVjkQn2GlhW4/oZZPtalCNTClf+9ncqzTUEo5YSG8g3vXfy3QsJFVgVh9EapxFDaM/NUjCEeuHU5ui/XcsuuWHODRbp45TUCwR9ljEOgLhL3N7zzI152jg9kaaDooCwDvIQF7yOSjBmuCX7S7CI=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(39860400002)(136003)(46966005)(9686003)(966005)(110136005)(478600001)(66574015)(8676002)(33656002)(86362001)(55016002)(7696005)(2906002)(5660300002)(4326008)(26005)(47076004)(8936002)(82740400003)(53546011)(70586007)(83380400001)(336012)(186003)(316002)(52536014)(70206006)(81166007)(356005)(6506007)(82310400003); DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2020 17:30:19.2225 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c35fa97-cd2f-49e3-f622-08d895559bd7
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT061.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6139
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/NttK9XguuWHYx_Vqeg_qeqPQPiM>
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2020 17:30:33 -0000

Eric,

From the discussion in May 2019 we agreed that we would use the CWT registry for the claims in the EAT. This was a good conclusion.

The example with the YANG specifications was, if I understood it, just an example.

Ciao
Hannes

-----Original Message-----
From: RATS <rats-bounces@ietf.org> On Behalf Of Eric Voit (evoit)
Sent: Monday, November 30, 2020 6:20 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>ca>; Giri Mandyam <mandyam@qti.qualcomm.com>
Cc: rats@ietf.org
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

Hi Michael,

This thread reminds me of some of the EAT draft adoption discussions from May of 2019.   Some of the threads I remember from the discussion include:

https://mailarchive.ietf.org/arch/msg/rats/7Uzkd84plkQ_LJ6oUYTQ3iwkmws/
https://mailarchive.ietf.org/arch/msg/rats/KPU6WgiCGkT6mUTbf5Ga41KwSNc/
https://mailarchive.ietf.org/arch/msg/rats/jBCYPK2hly554HGYTXZXa2t_AGw/

At the time, there was general agreement that where object definitions existed, it would be good to re-use them.  That would reduce the mapping needed between IANA maintained object definitions between technology spaces.

Below in your email you point to a list of YANG specifications named within draft-ietf-core-sid, section 7.5.3.  I think you are doing this for as a starting point for some object definition contents.  Am I interpreting this correctly?   If yes, this is exactly what I was hoping might happen.

Eric


> From: Michael Richardson, November 29, 2020 3:18 PM
> To: Giri Mandyam <mandyam@qti.qualcomm.com>om>; rats@ietf.org
> Subject: [Rats] challenges of building dependant specifications
> against Internet- Drafts -- a way forward for EAT
>
>
> Hi, sorry that I missed the RATS IETF109 meeting: I was engaged as co-chair
> of ASDF at the same time.   I watched the video.
>
> I think that the many EAT concerns are now at the point where more
> conversation probably will make it worse rather than better.
> It's time to move on with the EAT framework: many of the issues
> discussed will become much clearer when it is used.
> That's why we have "PS" vs "Internet Standard".
>
> I found Giri's presentation interesting: I scanned through the FIDO
> IoT Onboarding document, and I have no idea why FIDO needs to re-invent
> (Constrained) BRSKI.   But, I'm excited about it!
>
> The more the manufacturers understand the need for device identities,
> and for a "home base" (A Registrar), the better our whole industry will be.
> When MS tried to do this with the XBOX-1 a decade ago, people cried
> foul, but maybe they weren't ready for this in the home yet.  We
> certainly need it to be standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.
>
> The single reference to RFC8366 did not explain why that document did
> not adopt a semantically compatible voucher format.
>
> draft-ietf-anima-constrained-voucher explains how to serialize the
> YANG to CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
> This is then signed with COSE.
> {Or CMS, but that option is going away}
>
> The result is almost *syntactically* identical to an EAT (a map of
> stuff signed by COSE)!
> But the semantics are a fair bit different.
> Vouchers contain many things which I would not call claims, but embody
> essentially a single claim concerning ownership.
>
> draft-ietf-core-sid establishes a registry for SID values, which as
> essentially map keys for CBOR.  It has been difficult to get the
> document to advance, and until it did, we couldn't figure out how we'd be able to do the IANA allocation process:
> hard to get an early allocation against a registry which does not yet exist.
>
> What we did, and what Giri could ask the EAT authors and WG to do is
> to allocate some claims in the initial IANA Considerations section.
> That is, until such time as the document progresses through the IESG,
> the WG and the document authors essentially act as IANA.
>
> Here is what it looks like from draft-ietf-core-sid:
>
> section 7.5.3 (of sid-14):
>
>    Initial entries in this registry are as follows:
>
>    +-------+------+---------------------------+------------------------+
>    | Entry | Size | Module name               | Document reference     |
>    | Point |      |                           |                        |
>    +-------+------+---------------------------+------------------------+
>    |  1000 |  100 | ietf-coreconf             | [I-D.ietf-core-comi]   |
>    |  1100 |   50 | ietf-yang-types           | [RFC6991]              |
>    |  1150 |   50 | ietf-inet-types           | [RFC6991]              |
>    |  1200 |   50 | iana-crypt-hash           | [RFC7317]              |
>    |  1250 |   50 | ietf-netconf-acm          | [RFC8341]              |
>    |  1300 |   50 | ietf-sid-file             | RFCXXXX                |
>    |  1500 |  100 | ietf-interfaces           | [RFC8343]              |
>    |  1600 |  100 | ietf-ip                   | [RFC8344]              |
>    |  1700 |  100 | ietf-system               | [RFC7317]              |
>    |  1800 |  400 | iana-if-type              | [RFC7224]              |
>    |  2400 |   50 | ietf-voucher              | [RFC8366]              |
>    |  2450 |   50 | ietf-constrained-voucher  | [I-D.ietf-anima-constr |
>    |       |      |                           | ained-voucher]         |
>    |  2500 |   50 | ietf-constrained-voucher- | [I-D.ietf-anima-constr |
>    |       |      | request                   | ained-voucher]         |
>
> +-------+------+---------------------------+------------------------+
>
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.