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

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 30 November 2020 17:36 UTC

Return-Path: <evoit@cisco.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 C7FC93A09CF for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 09:36:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iijtSlAo; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=RuBk4wfP
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 dFzBBQWO4Rdh for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 09:36:52 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C3F3A0FF3 for <rats@ietf.org>; Mon, 30 Nov 2020 09:36:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13323; q=dns/txt; s=iport; t=1606757799; x=1607967399; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t15l/RjcBBIFegi10qfV0MUCkosWjJmslHhRSt+ep9c=; b=iijtSlAouaTWdosP0giraAGe6ZJBESnkCvZ46oOSBNrPDdNY0l8J0ty2 T6yOchr+3yLiZAJfVwnpRKsDgDP7VmTqB2LsnsBLTjoY2QblB5ynSCEtY BLoovumIRv+3pJHcivIR7I0XwfdIRFcmN+PHI/GifDXbFhAhkC7RqSvc8 w=;
X-Files: smime.p7s : 3975
X-IPAS-Result: =?us-ascii?q?A0BpBwAhLcVffY0NJK1iHQEBAQEJARIBBQUBgg+BUikof?= =?us-ascii?q?C0tLy4KhDODSQONWpkGgUKBEQNUBAcBAQEKAwEBIwoCBAEBgVWCdQKCKQIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBBBIRHQEBLgkBCwQCA?= =?us-ascii?q?QgRBAEBJAcCAgIwHQgCBAENBQgGFIMFgX5XAx8PAQ6iMwKBPIhpdoEyE4JxA?= =?us-ascii?q?QEFgTMBg1UYggkHAwaBOIFTgSCDdoU5gR4bgUE/JmtDgicuPoJdAoEqARIBI?= =?us-ascii?q?wUQIQKCXTOCLJA3HIMph0ydJgqCcIRUgmaBXYwMhiuDHTmJZJRahgyNBVSLB?= =?us-ascii?q?5VoAgQCBAUCDgEBBYFtIWlwcBU7gjUBATJQFwINjiELARcUbgECgkmFFIVEd?= =?us-ascii?q?DcCBgEJAQEDCXyNOAGBEAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3A3/Jq5RJPbpfrJZUewdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK0/hUXMG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKyK00TE8H7NBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,382,1599523200"; d="p7s'?scan'208";a="641510265"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 17:36:32 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AUHaVrW016147 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2020 17:36:32 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:36:31 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:36:31 -0600
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 11:36:31 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XbmOdMu4hPb504tJsTFcuxcxeR0ko4MoBPESR93arbelKO8eHuwkvPRKflT+Hk8Snh6JK4rNkdFFaNlE/9KchZzeUwLrCMnzeV+bGux8ScBH0hD8xNS1OkopAhBg/nEKoTr07zvDLtPKeQZ6ONZu3LdnwXeNDj3E9bXP6jrhBx0CA3HhjE8i8YXVMg/khHzsr7rPZExv1E2u/AdNHMiwAXBp4qPcLleyVpJC5hGRrvh+dKTr8keE0beZfZ1ZEt5J7HM4GuKxyM27UeB7FRTsyp31ewKMasQtXHs0oTc3sxVjoJIoera8sHebYIpQOd2Grs9tJyXg4e50sZa9zAprog==
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=R4zzUlF49vPkwRrjJzDelOMGZew5aPwXx5kLSsb2p24=; b=hcxhGH7XsiOgS9vQJuKKIFfwQd7haV4dZzmZpRr5HEAC7r3ZPAHdJcHBUjF58xeksEX85oq1ndmXBQogILZXmfs4nwEdHuseydy34luLoPBTUkEh4JKe0ux2qVlFJXqwKJnwJV/iU2IxeCTVV2ajUfqiICtVFRIkbhQp+oFHUICtQEqxUiCtVLWjyvHlFL41MajpAlNfK+QHCRTbiSjhZ5Iziq3loKObRkVrdJEqsRusHrzBFSA3+KbTFtFJpb8EbfG+PTegeiE/Xj63s1NiMjQWWBtSkRqMhYRYksnLNZlTcuNrxG53ssRAHltzfeKMaNfOkbS8iJRcjx5UIW3QAQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R4zzUlF49vPkwRrjJzDelOMGZew5aPwXx5kLSsb2p24=; b=RuBk4wfP/nxXNMK6QIastIqmiSZ3GwjsVBx3osqWD9YiItgUs+fqmujQ9LfMseI4S90lxx6CLEND6WH1dWtkKg1HUYnWWSlxCUmz5XvBjDdRd2+Bw0C8ZgJGmZLxKoi+FS8Yq+d+dU4bSAx+odfhUCJy7b5IElmd8fYTkRf1BLQ=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4352.namprd11.prod.outlook.com (2603:10b6:208:18e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.23; Mon, 30 Nov 2020 17:36:30 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::9851:12ed:f9df:af4f]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::9851:12ed:f9df:af4f%6]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 17:36:30 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, 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: AQHWxozTuKiYQWjnwEyQn7ccQdiVRqng59jwgAAH+YCAAACPkA==
Date: Mon, 30 Nov 2020 17:36:30 +0000
Message-ID: <BL0PR11MB3122D35683FD909A3C80E4DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <24519.1606681083@localhost> <BL0PR11MB312296BEFD428C6D9CE9A5DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com> <AM0PR08MB371606D3753BED36E71A5754FAF50@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB371606D3753BED36E71A5754FAF50@AM0PR08MB3716.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [108.18.114.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4772c21b-456c-4999-eb44-08d895567924
x-ms-traffictypediagnostic: MN2PR11MB4352:
x-microsoft-antispam-prvs: <MN2PR11MB435210480917E20EACE41CF0A1F50@MN2PR11MB4352.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4G6DKt5QoXf7q1F+L8h7y75rtpuKiXYK38CxdTBDc7sS1T3+75pTmy8bUhhS4khMqh+lgrstEjij9xFuunNxsMFzulNoEK2qs28gVy4NLzzgBPDq+9XUSrKcmTrEwkJiePYPuYI0iMlze7R8O9SxkuLvvYavPFY41Ov6yl6SIqe72hWCTR4Cw64wQQ1EQVAzt/+F1yuVfMFyhxbN2fNqho7rgXrk/Rbh8ugmKS5TSKeQKmLoe0nfc3fbiE63kFG9WoVAgiw2CevIx7hHgF3s3EIsGn53nxJ5Nz7QHKS3dc+21ZIdrzEatRXBbf0w6Ijnm6XA5GejRu+a5d/CPwpd9t6bEP+FOf1DOZ1cIe1RI6sf6B6EmovGI6TQMY82HkuoYgGYCCPKStKWs/X6dTaN9g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(39860400002)(396003)(136003)(83380400001)(52536014)(8676002)(5660300002)(966005)(71200400001)(110136005)(316002)(8936002)(478600001)(33656002)(2906002)(66574015)(64756008)(53546011)(4326008)(6506007)(86362001)(186003)(55016002)(9686003)(99936003)(26005)(66476007)(66616009)(66556008)(66946007)(7696005)(66446008)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?S3JNY2dUdXhad0ZvNUpjVHJTOTVoTE16bVUzVzZBUWRmWHJwRVU2MTBSUmdj?= =?utf-8?B?cU11d3ZGbFQ0enNKdTdDaVZTVVVJTWNLdWZRcXJJZ0EydWpvWGQ5ampkZ0tj?= =?utf-8?B?YXd4K0ZCS2xYZzlFajQ3aS9yQXNIVG8yQUh0dWF3Zk55SkRrQXVYZ2NuWDZi?= =?utf-8?B?ZEZnaWJSSTlxcWtEaTFDN2pwQ0paSHRHb2lVY0gzd1dwOVJYMklNQm5sTURM?= =?utf-8?B?RFlNSUp0cVlvektaYUl0UDJKNTdJK2ZVWUxOOUx6Ti91S3FmTXNsT014dFUz?= =?utf-8?B?YXlKZDRYdDZJY3VMZURQZHh1UWRzVHZjRTRUNG4wY0FiY3hoNXMrdzZ0ZHpm?= =?utf-8?B?NWx4Qk5McDJqWmN6Uk9yZXI1N0xET2F1eHN1TUwrWFZyWmFvWEJpbEhFcGJJ?= =?utf-8?B?TmlzSG9vSUE4NmhMY3Z1bzY2MkdyRFNrSDNTYjNKM2xpR3p2SDhqZXIvSU5Z?= =?utf-8?B?TlcrSXIzc3FpR3oxaHhGYUhZWGNzYkJHRFNhaXl5TDlNMkt2TUJwR2JnR1BP?= =?utf-8?B?SHY1WnJsVWs3Q24zTmp5WTU0cUlJUmNDSjZpMS8zYUZqd2tvOVMzK3VJRlBN?= =?utf-8?B?bDNCRkUvT0RtWFBwYWlmQUplOFRibFBnMEEvTHhpNzdCNlA0czk5MHljMHBy?= =?utf-8?B?VXFVc1diWlp3MmhXZW5lTkx2NjFjOTJZVThzZTVWVkt4dnNHeXhaektEc1Vh?= =?utf-8?B?WWEydXVqUVc5WmtNSkF2TUFSM1ZkamJLNWN4UUI4Wjg3THJLMHRNTWFSZHVJ?= =?utf-8?B?WTM3ODBSTWVrYmVtc0FlVy9vWlNhbmN0US9yaElvdHo2NUxDSTl6dng2NG9l?= =?utf-8?B?dWpNYTRnblJ1N0hSWXlGd0RXLy9oWEJ0eWRnQWk5UC8vZ2xDNENUdHRZcGhT?= =?utf-8?B?RFJSSTc5Wmh1Ti9YSVk1MXJhR0hINS92ZkQ2OVdTbWR0RnpsMEF1N0gvUklD?= =?utf-8?B?eFdDZFgydzEyQWN1cy85ZG11citGaXk2V2N2VjhZWVRrbkU3WEZhSjlwTVpi?= =?utf-8?B?U09NbGtJaUFYUnRFcGYvSStDN2hMeS9tQ1d6MVZrNGsyWkd0b1VnbmJ6M09l?= =?utf-8?B?ekVKbDVXcUp2ckFDcFkzN0dBc1BCK2NOSGZrczExRDRwQ2ZXTll0MWNPTlBF?= =?utf-8?B?YkdGd0k1dERLcTUrNXp0MXJEdE1EamdJU1lJcUszLzl4WC85UmF3S1lrZ2Qr?= =?utf-8?B?b2VQakVMN1ZHOEI1RkpQZjdLcWZwd0dzbHV4VTVJWXBHbFU1QURRZ1ZRVmtj?= =?utf-8?B?cjFobmlmNTRQTXcyNlpCSmdSK0IvdVQ0YXVTZnVmcGFVSmVYNkkxNm9mSGtW?= =?utf-8?Q?RbPSL2MGRFMjA=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B7_01D6C715.6BC52090"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4772c21b-456c-4999-eb44-08d895567924
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 17:36:30.3794 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: O3bFQVsL3jM8X9xiI6VTZ0xFUe/9oDyx9HIJNgsLJbzw6WdTIautSkI3lL0RZ3ie
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4352
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/cdLiB15sTr3IkBSv8OGaA37aN10>
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:36:55 -0000

Yes, we agreed to use the CWT registry.  I also recall using YANG objects and a potential definition and range source for any new claims that people wanted to add.  (I.e., if it exists, let's use it.  And then we don't have to worry about cross-domain mapping.)   My reading of Michael's email is that this was the purpose of the table included in the bottom of this thread.

Eric

> -----Original Message-----
> From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Sent: Monday, November 30, 2020 12:30 PM
> To: Eric Voit (evoit) <evoit@cisco.com>om>; 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
> 
> 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.