Re: [Int-dir] [Drip] Intdir last call review of draft-ietf-drip-rid-26

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 17 May 2022 08:27 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F3C157B4A; Tue, 17 May 2022 01:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=JpQA/dVj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ObuPC0U5
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECHfFy1gui78; Tue, 17 May 2022 01:27:53 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E35AC14F716; Tue, 17 May 2022 01:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24336; q=dns/txt; s=iport; t=1652776073; x=1653985673; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L6lS+8yPQnbzx20ovR6A2ZrPMKdu9E5dmNNIzzFm69Y=; b=JpQA/dVjcclcunCerpkYxFldWqK3Hkrz2jvx4/+cZxGJcqUk/xB4tKxK 55sFYZoJr0O3L8wUo4inULMI7gQD93KtpCeNjg0THrEt43Q9s8PcIVBvF 5hndvvBwPjNhi+ZMJe/xxuDADrPj8b8rew4tgsi0y4qnBI48+ZxLGbHDF 4=;
IronPort-PHdr: A9a23:4BNcSBIYvMR93FhnAtmcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8EYxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig=
IronPort-Data: A9a23:1Y7WY6DPjGYfGRVW/9Dhw5YqxClBgxIJ4kV8jS/XYbTApD0rgTVRx2YZDW2COfveZGP8eN91bovn/R5UvJCGnNFlOVdlrnsFo1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNPM7EsEOhuFiWG/kr0bOC4xZVB/fjgqoTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u2je5RpoU4rjmbfgeUpMSbnXVeSMoiMJAO753V4T/WprjvlT2Pk0MS+7jx2Rg9BswthXqbS7SBwiOevHn+F1vxxwTH8nZf0WpOOWSZS4mYnJp6HcSFPwxrB0DU0ePIAE9KBwG24m3fgRMyxIZRmHg8q3za61DO52iawLINPiMp9au3x8w3TVF/c+BIrCT+PD4dtw3TosiIZJB/m2T8sfdX9jbQ7oYhBTNBEQEp1WtP2ng1H7ejdD7lKJue885G7I0QhtlrPqNbLolnaiLSlOtlyTqmSD9GPjD1RDbZqUyCGO9TSngeqnoM8yY6pKfJXQyxKgqAT7KrQvNSAr
IronPort-HdrOrdr: A9a23:SH/ZmqOyuto+P8BcT2D155DYdb4zR+YMi2TDiHoedfUFSKOlfp6V8MjzjSWE9wr4WBkb6LS90dq7MA3hHPlOkMcs1NaZLUbbUQ6TTb2KgrGSuwEJlUfFh5VgPMtbAspD4ZjLfCRHZKXBkUiF+rQbsaO6GcmT7I+0pRoMPGJXguNbnnpE422gYypLrXx9dOME/e2nl6x6TlSbCBEqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEw9n8PMHyyzoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyTpAJb4RGYFqjgpF5N1H22xa1+UkZC1Qefib3kmhO11dZyGdgjUIngxes0MKgmXo8EcL6faJNA7STfAx3r6wtnDimhcdVBYW6tMQ44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1UwKp5KuZJIMvB0vFtLACuNrCq2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZNyLstD51fo+jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR52Mi6PJgTiJcikpXIV11V8WY0ZkL1EMWLmIZG9xjcKV/NFAgFCvsukaSRloeMMYYDaxfzOmzGu/HQ18kiPg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BtAABDbIJi/5NdJa1RCR0BAQEBCQESAQUFAUCBOwgBCwGBUVIHdQJYOUOEToNMA4RSX4UJgwIDgROPNIYTgTSDKoEsFIERA1QLAQEBDQEBOQkEAQGFAgIWhSgCJTQJDgECBAEBARIBAQUBAQECAQcEgQkThWgNhkIBAQEBAgESCwYRDAEBMgUBBAcEAgEGAg4DAQMBAQECAiYCAgIwFQIGCAIEAQkEBQgTAwSCXIJjAw0kAQ6QMI83AYE+AoofeoExgQGCCAEBBgQEhQ0YgjgDBoEQLAGDE4MFWEyEcIEUgR8nHIFJRIEVQ4IwBzA+gmICAoEyAwEKBByDVDeCLmOQDYITgkcdOwNUgQUSgSFxAQgGBgcKBTIGAgwYFAQCExJNBh4CEwwKBhYOQhIZDA8DEgMRAQcCCxIIFSwIAwIDCAMCAyMLAgMYCQcKAx0IChwSEBQCBBMfCwgDGh8tCQIEDgNDCAsKAxEEAxMYCxYIEAQGAwkvDSgLAwUPDwEGAwYCBQUBAyADFAMFJwcDIQcLJg0NBBwHHQMDBSYDAgIbBwICAwIGFwYCAhlYCigNCAQIBBgEHiUTBQIHMQUELwIeBAUGEQkCFgIGBAUCBAQWAgISCAIIJxsHDwc2GQEFXQYLCSMWBiwLBgUGFgMmJysFBB8BG5I+gx0IgQ0BUhkGAhURCjIEFAQXAhIIBgIFDwUHAg0XCTYMBwEbGQoDBAEFBgESFhlLkgESCy2DH4o8jUWRVIEnCoNMoCYVg3WMPoQrkGiCF3qWZiCCKp53AikEDw2BY4MPAgQCBAUCDgEBBoFhPIFZcBUagwlRGQ+OIAsBFoNQhRSFSnUCOQIGAQoBAQMJjlIBJ4IgAQE
X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208";a="761088449"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 May 2022 08:27:51 +0000
Received: from mail.cisco.com (xfe-rtp-004.cisco.com [64.101.210.234]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 24H8RoD7006549 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 17 May 2022 08:27:51 GMT
Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 17 May 2022 04:27:50 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 17 May 2022 04:27:50 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aADU6RJZFvb+4k2oFUU9j2QAD9LrjcuUn6O1O0rmudVA5D/dKtE1nnVfSJ+4uDCbXrMmrAJcKoFUgKjJBWoOh1WUvXLd1n3d67QMro5yhWrcxMZB2clQkmDO5ySi1a5g53uemS48r1yGu2GqhmEoD/A3QLhbV09h6PDWyWqAV5wg3jkC3VnRpoKsY5Kocm1/cg8HR0Zorze2fsE6BcVuLr4g0hPmtSbg249Fgn6j9oEu4AGxIRkyyRsT7n3aOeT0EE8Gc8Bw/k4Tta81y4KmJFYEMxj4b1V+204QNToADTmycPVKua1BRM1igzPMtZ/rrX4HlBlXpZaSMpadlHyM6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L6lS+8yPQnbzx20ovR6A2ZrPMKdu9E5dmNNIzzFm69Y=; b=Dd/CnHmrtEINlrvz2lTkZJds1HHuXqmi4d9Rp5SwiYzHs9mSo/F4G/vySIIW4UwLEvhsaf6hEPsp2cWwu+8MUMhOBA+mccve5YsHzihapCcezt+Ig0gNTNNM72ILbQLdSkUjm+NIhwoy4zpGnLeXILXtV0dTyMe9zkaO9IXUlWQbDigQKyaN6eFFP1WzniyxTIbpKy2x8D34Aci5IhINyROStLBQgFmtl5+DTCNB5jmCuMRfGAlGCxvwhCwFLMQLDvXdeVTq4r6G8V7/5BBeZfYGRJl2xKPR0t41m8RYGIF83BnVtkzLkMSpyYR/Ip+QgqZC4+oBFMHTcrGKNg2npg==
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=L6lS+8yPQnbzx20ovR6A2ZrPMKdu9E5dmNNIzzFm69Y=; b=ObuPC0U5u/+5r6FnVtYi+L1zI6Xh155z4cgM1VM/H0KHdWb7+k26QPA6FFHKUKownBYbA0gJhvkX1s2vTEUyjLWJNNNAD+zb/Ht8AFPFl0H8Nl2rtFPBGQfYquItkaZTNGA8QzFcpLsG18DhvccgIyYsVy0Gfon3wm1gGF1NDP0=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by SN6PR11MB3357.namprd11.prod.outlook.com (2603:10b6:805:c2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.18; Tue, 17 May 2022 08:27:48 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d168:bb8c:2e0d:2ed6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d168:bb8c:2e0d:2ed6%7]) with mapi id 15.20.5273.013; Tue, 17 May 2022 08:27:48 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Robert Moskowitz <rgm@labs.htt-consult.com>, "int-dir@ietf.org" <int-dir@ietf.org>
CC: "draft-ietf-drip-rid.all@ietf.org" <draft-ietf-drip-rid.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tm-rid@ietf.org" <tm-rid@ietf.org>
Thread-Topic: [Drip] Intdir last call review of draft-ietf-drip-rid-26
Thread-Index: AQHYaVKouMBnwluTwEOMIIUxig6Yx60h1Szw
Date: Tue, 17 May 2022 08:27:19 +0000
Deferred-Delivery: Tue, 17 May 2022 08:26:26 +0000
Message-ID: <CO1PR11MB48816933C00D28EA05C5B0D2D8CE9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <165270781174.61908.279324826477098049@ietfa.amsl.com> <e49c776b-0fdf-9009-192a-944d2c633cd3@labs.htt-consult.com>
In-Reply-To: <e49c776b-0fdf-9009-192a-944d2c633cd3@labs.htt-consult.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5821b2ce-28df-4a65-b82e-08da37df2002
x-ms-traffictypediagnostic: SN6PR11MB3357:EE_
x-microsoft-antispam-prvs: <SN6PR11MB3357F14F88E7EDA1C6F8901BD8CE9@SN6PR11MB3357.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FZCWLdCSBGTy23q76IehJaDYZ+niQRcBmN6fMH4R5BOkLvgoMFdhAAOizxwfnC3XMSwLwklM11dR5EJea4Bw6m2Fg6HrsAt7q62j/96/jI81J0mJT6nh+szor92of+pfkbf0VZ9OgkV5l1UfGih1UJUSrqmqV5wE266cU9Ag1kur5R+NyUJd20Y4ew2h3sepTTX7W/+kDAHR1q5F8b+3UR5hLKb5e6Q90h0fPGY2d+EyW+mZqV7gOGd1ZdwT/cbKUa4MOl6B0aKEpjrBMxl7dZqOR8kB8sUCuzITtrrD2OFHePUY9wQ/Xw3phq4gnGCSPMV2D/k/XDoQKQpxxvdp/RyyBX8gisNPh2VKAHIx6pOhbwP2tcyBfgO2L4tz1aWQYeW057OO/8dcsIQuzMhm9MHZTOUh+f6AMaCTbHe4WGYYTSR7UeXLJHo8uSV3sY3Civ6O118/DcpVV5yJrDTmb7Y5ZqxPwDld9Of+i1xOeZVKb58G9SHYoCHbmkFo0Qino1fwtNrZ1IUJQAYEFJ8H9lNMvQxHuTI5EGrtA9hPrCnPkAH3ycpI9hsSdTPgBEZJRrpdOuYGOIKgn122VqMYyItsRlfGyzwiY8oFNNqNJjsT8QNOh1v8vxTyK2O0KYaOxBIEHxIWejC9ht7NI+CLCPbRGBRvpsPtRRwHPgMNQqs6qHPWv1xNjWQp9F5HqUv7MAeWrbs3AXAIdyl7QpN8gS/fGUm3TRwnsK/x2KHncqg5DBtOjsYE4mSJNimvv3zuySrPSzirS9LKE+dzyZgnJAxQWcfBZwoit1AiC+iy377/blxpPUjrna+ZJ4bo66uRCBWQpgY5IAOCzT+7+XNhoA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(64756008)(76116006)(66946007)(66476007)(66446008)(8676002)(4326008)(66556008)(33656002)(122000001)(7696005)(6666004)(316002)(38070700005)(38100700002)(86362001)(66574015)(30864003)(83380400001)(8936002)(5660300002)(53546011)(186003)(71200400001)(6506007)(26005)(9686003)(966005)(2906002)(55016003)(508600001)(52536014)(110136005)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 2Mp35VdmEduLO3wdrOA48kk/GIFtwEmzaMc4kcqB4y618QxGX/2QytlIYB3BgMRZkYtdgbuxgoklsOCCk34T5kFzAosDpWIazptyq/QTcQDc+r5LL93tvKsmSN9xvga+8rzNFgsbX9uEGmJM/u3yB4m8lJKfvS6U/SVoJIf9VvGp10P9QwpxDt8cFwcSmKzyj7gPgT7bGcN5TyBlAp1LMWTCkbdHChtZHz5HfRqXW8a0Mq+0+MIORuMwlWgWOp/ssCUvym662Rn/LmoMJm9PP1xwxaHEJSfu10BhANSb6QZfgpMmvOXaki/iuMIYGFx17Wc2bb2F5T8tOUD0WS9GCZXNW16GguI1+s31vU+OVAtvwVykdUXbMiJHUfKsvsrk+Dr/uApWJhv1u7jBCHN6CihgxB/hZmVaa534PM331gE3t8MO5HtzgLEuO2nwaWt+4LCO6rpJ89OKUs+XGTNAMaVTHSXxbgm9l/oQD8+G1iZL3TTthii9oK/252Hmioj8MI4u79r4b5gRAiOE9Itv4IJZtV0NGtG53s+chJ1e3TyrFFUcoupo3qHwA8GYcMWqB2EsVzYWyCluaPXlA4LGoZMiOPhAb9NFBYYrDua8DTpiwYTfyi3VnbXhieXcCobjQfMkQqA/3poq15joscMv8GvdkrMPChsBXqRlLODB7j/SQ14VTwy8WBFLSkg/Fv4Z28b0COCH0sH8gTHhc+T8M4okihPLMXiDEXySDvyGY0NHYURivFlxwuAF1QHBLBK8OPZl9R4zGZtdJsXF4EDNbbbALnVk4ckIjp7vcRQ7mxXr/4QqcNF6gFAAqF5TLgr0Es4HREtd50jGvxWarQmhT36iJ/2FXws5QSyidC0WomDT7LZXDrj9hnki90NBIsY9yPdE6XQWAV8ijoAKB+iQhMI+LveDEH7fcYEN/n2VNLk/kT2Q7kmOa2yEEMkSeisURi2CG9zSR7BMyuSSjFZZoRZ+6pynUGXbtWyouVT/lfE6avije+Je00YsneEPQvpJqJ5a48Fl9x9SYY87IPa/a09bYL8jBXd2pc74axfDv9DTswR4gRJHKXBmf5AgsD3zSR0m1FDIWRu6rvV7vD787ZMYXUq5nu0OG621nORnclKesz4imeAEP+qNfAiQYkVp2KuvaFpee594AXpQ2j5ggoJkAVgehtvbMWc/hNfEjrDmisMlMCtGHZibb0dAUm+oeP7ClgHKGhgoMwjNKHKc0PtdOVDMlELlwJaotYAceVIHQsCBrFJ4oxI0lhOAoAuApVR+w8SCpOw4fGjPBzaYYP4BmiUoJswvkg8ACXc7nUPX+QMaiazUhMtRMYnO3HoPJcvNQxSk83JZtznjxwfhXHtmjQxADcXeHbQonfBKJHNTXqHdCiFxcMo2jo0PSOQP6WMckYLlHOjfpSPZOYz52qWa0GHhxGz/LsRDhorfpAZCcKTHMX9GlchYqsAnY/5PJ4d10V0Yc/+PjWjt0dTzc2rmvnXtjSRbTaR/P3bwT40UXIKzWLRnVMlhZYgVRyrWQJGXCbwDZClnVoEvcal7bWw0BDWlOvvk3gtOrCviHoOARSa5eN2nEaf2q45OWUCBm8/ha7R3Mkux1UZsKUfECAqrLTVGH4DxG0TbBA40Uv02WhlbAETFG5fk8E+NWdsh1nx7YbSP3NQVtrmVityaXKKHFMWiGi9CHMmjPXtixEOzGxgNRCdVHkFViYKLf+JIF8UILGyBuD5P/z8P/ogu7Q==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5821b2ce-28df-4a65-b82e-08da37df2002
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2022 08:27:48.0163 (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: S4kFHsRCUns37BQ0sl2IpyGvwB0VjdNrVhN102SVLv3T+6R0ra61H3ZpCf4kOjyJsXkACDGUyS6MWcuVVrM+ig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3357
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 64.101.210.234, xfe-rtp-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/5GmRn3EzoCrAAIxEDgyzQDwG7ao>
Subject: Re: [Int-dir] [Drip] Intdir last call review of draft-ietf-drip-rid-26
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2022 08:27:58 -0000

Hello Robert

Most of my comments are indications that the reader might wonder what I wondered, and some little editorials at the places I ticked could improve the readability and the smooth transit through IESG. In particular, having an appendix or what that discusses the address as an ID and fwd pointing it in the intro, would save predictable hassle in the next steps IMHO.


>>>
>>>    HHITs are statistically unique through the cryptographic hash feature
>>>   of second-preimage resistance.
>> Good thing that the HHITs are Hierarchical as opposed to only Statistical ;)

> The original design for HITs allowed for a 1-level 'hierarchy'.  My 
> co-authors at that time did not see a use for it and we removed it, but 
> go back to draft-moskowitz-hip-arch-02 and later 
> draft-zhang-hip-hierarchical-parameter.  Now there is a use case and I 
> believe the design is good.

Since that was you and your keen eyes, I took the liberty to add some amount of second degree. Sorry I should have hinted. 
In this case, my poor sense of humor - though the first degree was very true too.

> >> 2.  Terms and Definitions
> > A forward ref to fig 1 would help with all the bit fields.
> 
> Please check out changes to HDA, HID, and RAA.  How is this change? Do
> you want this on any other defs?

Happy to but where? Is there a github?

> > Could issues arise when the global registry is unreachable when the ID is
> > formed? Is the HHIT "tentative" till then?
> 
> Really can't use it until it is registered.  HHIT owner has no assurance
> that it is unique.  And if the RAA will accept the registration for
> whatever reason.

Actually this was an indication that the reader may be wondering and may love to see text enriched, with e.g., the above.

> 
> Do you think you can get IESG to 'vote' that DETs get a /24 or even a
> /20 prefix?  ;)

If your encoding is future proof enough... /24 looks like a good start, that 6MAN would love to see for the /64 alignment thingy; maybe ask for a /20 where you use only a /24?

> >> 4.1.  Nontransferablity of DETs
> >>    A HI and its HHIT SHOULD NOT be transferable between UA or even
> >>    between replacement electronics
> > Pro: This answers one question above.
> > Con: this bars very interesting IoT use cases I have in mind for spare
> parts
> > and sensory devices. e.g., ISA100.11a uses IPv6 addresses as IDs and would
> > benefit from this.
> 
> This is for HHITs as DETs.  HHITs (with a different prefix) for other
> stuff could have other behaviors.  I would love to pursue this with you.

Could we then word the above as " A HI and its DET SHOULD NOT be transferable between UA ..."?
The title is already fine but the text inside could be misinterpreted.

> This mirrors 7401 HIP registry which predates 8928.
> 
> I question the value, here in this registry, to go back to where each of
> these are defined.  Other than the referenced rfcs?

Reference RFCs is fine, that's what RFC8928 does when available. 
My point is that creating yet another registry is overhead. Happy that you extend the HIP one. In parallel, is there a way to fix the issues you have with RFC 8928?

> > is not post-Q resilient right?
> 
> No 2^64.  That was a error up there in Fig 1.  Thanks for catching that.
> 
> Not PQ resilient.  No viable PQC solution at this point that we can
> shoehorn into this small size dictated by other regulations.  One one
> hits the surf, we can allocate a HHSI for it.

Another instance of me suggesting to add a few words in the document like the ones above ;)

> >> 9.4.  Collision Risks with DETs
> >>    The 64-bit hash size does have an increased risk of collisions over
> >>    the 96-bit hash size used for the other HIT Suites.
> > Is that true also for voluntary collisions (brute force) ?
> 
> ?  that is what this section is about.  Straight probability stuff. What
> can be brute forced?

Someone wanting to create a key pair that would generate the same ID to steal the ID and impersonate. Is that an issue here?

Otherwise all good!

Pascal


> -----Original Message-----
> From: Robert Moskowitz <rgm@labs.htt-consult.com>
> Sent: lundi 16 mai 2022 20:27
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; int-dir@ietf.org
> Cc: draft-ietf-drip-rid.all@ietf.org; last-call@ietf.org; tm-rid@ietf.org
> Subject: Re: [Drip] Intdir last call review of draft-ietf-drip-rid-26
> 
> Pascal,  Thank you for your review.
> 
> On 5/16/22 09:30, Pascal Thubert via Datatracker wrote:
> > Reviewer: Pascal Thubert
> > Review result: Ready with Nits
> >
> >
> > https://www.ietf.org/id/draft-ietf-drip-rid-26.txt
> >
> >
> >> 1.  Introduction
> >>    DRIP Requirements [RFC9153] describe an Unmanned Aircraft System
> > Maybe expand DRIP on first use?
> 
> Done.
> 
> >
> >
> >>   asserting IPv6 addresses and thereby a trustable identifier for use
> >>   as the UAS Remote ID.
> > Architecturally speaking, people hate using IPv6 addresses as ID. I
> > foresee discussions about address renewal, device replacement (same
> > address?), and privacy. We'll see further down the draft but I expect
> > that a dedicated section on why this is desirable (and OK) so we do not get
> endless pushback at IESG.
> > https://www.rfc-editor.org/rfc/rfc9153.html#name-identifier does not
> > seem to enforce that IP is used. Also, interesting to figure if the
> > model is portable to vitually anything, e.g., in IoT.
> 
> I have been living this discussion for 25 years.  I have my Kevlar
> suit.  Part of it goes back to discussions I had with Bellovin in '94.
> Addresses are not trustable; it is reachable that gives a small level of
> trust.  Thus the design of HITs.  Lots of opinions since then.  No one is
> 'right', IMHO.
> 
> 
> 9153 does not enforce it.  It will be later work in other drafts that will
> leverage this.
> 
> And it was our intent with HHITs to it be available to other things. Just get
> a different prefix...
> 
> >
> >
> >>   Hierarchical HITs provide self-attestation of the HHIT registry.  A
> >>   HHIT can only be in a single registry within a registry system (e.g.,
> >>   EPP and DNS).
> > Could we imagine a distributed ledger?
> 
> Yes, Dr. Gurtov is proposing that as one solution.  It is in an appendix
> in drip-registries as an alternative backend.  Discussion of this does
> not belong in this document.
> 
> >
> >>    HHITs are statistically unique through the cryptographic hash feature
> >>   of second-preimage resistance.
> > Good thing that the HHITs are Hierarchical as opposed to only Statistical
> ;)
> 
> The original design for HITs allowed for a 1-level 'hierarchy'.  My
> co-authors at that time did not see a use for it and we removed it, but
> go back to draft-moskowitz-hip-arch-02 and later
> draft-zhang-hip-hierarchical-parameter.  Now there is a use case and I
> believe the design is good.
> 
> >
> >
> >>                            The cryptographically-bound addition
> >>   of the hierarchy and a HHIT registration process [drip-registries]
> >>   provide complete, global HHIT uniqueness.
> >
> >
> > Coudl issues arise when the global registry is unreachable when the ID is
> > formed? Is the HHIT "tentative" till then?
> 
> Really can't use it until it is registered.  HHIT owner has no assurance
> that it is unique.  And if the RAA will accept the registration for
> whatever reason.
> 
> >
> >> 2.  Terms and Definitions
> > A forward ref to fig 1 woudl help with all the bit fields.
> 
> Please check out changes to HDA, HID, and RAA.  How is this change? Do
> you want this on any other defs?
> 
> >
> >>   Keccak (KECCAK Message Authentication Code):
> > I guess the expansion in () is a CC from the next definition.
> 
> Actually from FIPS 202.  Copy and pasted.
> 
> >
> >> 3.  The Hierarchical Host Identity Tag (HHIT)
> >
> >>   *  ORCHID hash (96 - prefix length - 8 for HHIT Suite ID, e.g., 64)
> >>      See Section 3.5 for more details.
> > If P is 28 bits then the hash is 60, which is less than CGA; also this
> fails to
> > align to the usual /64, though whether that's important is debatable. Is
> there a
> > reason to allow P to reach 28 as opposed to 24? Will it be harder to
> allocate?
> 
> Good catch.  Thanks this mistake goes back to 32-bit HID and 4-bit
> HHSI.  Lets see what this should be.
> 
>     *  ORCHID hash (92 - prefix length, e.g., 64) See Section 3.5 for
>        more details.
> 
> We debated byte alignment.  At first we chose to design for it, but the
> request for an 8-bit Suite ID rather than rfc7401's 4/8 design made us
> drop it.  Developers were ok with it.  So no byte alignment.
> 
> As for a smaller prefix, it would be GREAT.  But I am not sticking my
> neck out for one!  I have worked out, that in practice, a 28-bit HID
> really should suffice.  But a smaller prefix = a larger hash which...
> 
> Do you think you can get IESG to 'vote' that DETs get a /24 or even a
> /20 prefix?  ;)
> 
> 
> 
> >
> >> 3.1.  HHIT Prefix for RID Purposes
> >>   Initially, for DET use, one 28-bit prefix should be assigned out of
> >>   the IANA IPv6 Special Purpose Address Block ([RFC6890]).
> > Same as above, are we reducing the security properties by having a /28?
> 
> 
> Yes.  We rely on the registration process to deal with the 2nd preimage
> attack.  Along with some lookup or authenticated source for the HI (see
> drip-auth and how a 200-byte auth message can provide the HI, signed by
> the HDA's HHIT).
> 
> But some will argue that even a 68-bit hash will be attackable in the
> foreseeable future.  At what point do see good enough?
> 
> > 3.2.  HHIT Suite IDs
> >
> >
> >>    The following HHIT Suite IDs are defined:
> >>
> >>        HHIT Suite          Value
> >>        RESERVED            0
> >>        RSA,DSA/SHA-256     1    [RFC7401]
> >>        ECDSA/SHA-384       2    [RFC7401]
> >>        ECDSA_LOW/SHA-1     3    [RFC7401]
> >>        EdDSA/cSHAKE128     TBD3 (suggested value 5)   (RECOMMENDED)
> >>
> > I checked the IANA section. It's there though
> > - missing references
> > - duplicating other efforts for similar registries
> >
> > e.g., https://www.rfc-editor.org/rfc/rfc8928.html#name-crypto-type-
> subregistry
> > Could you reuse that registry and extend it for the new suite IDs / hash /
> KMAC?
> 
> 7401 registry predates 8928 registry and that is what we want to
> mirror.  I did not spend any time or had anyone recommend investigating
> other possible registries.
> 
> > Adding Keccak capabilities to the previous RFCs is a win/win.
> 
> Yes indeed.  There is a lack of energy to do it, though.  It seems.
> 
> >
> >> 3.5.2.  ORCHID Encoding
> >
> >>   The cSHAKE function call for this update is:
> >>       cSHAKE128(Input, L, "", Context ID)
> > Is there a way to add a "salt" so that the node may generate more than one
> ID
> > for privacy?
> 
> This is used over a broadcast media.  A private salt would really break
> a lot of pieces in the architecture.  I did consider it, but then
> authentication for verification becomes mandatory, and well things
> snowball from there.
> 
> >
> >> 4.1.  Nontransferablity of DETs
> >>    A HI and its HHIT SHOULD NOT be transferable between UA or even
> >>    between replacement electronics
> > Pro: This answers one question above.
> > Con: this bars very interesting IoT use cases I have in mind for spare
> parts
> > and sensory devices. e.g., ISA100.11a uses IPv6 addresses as IDs and would
> > benefit from this.
> 
> This is for HHITs as DETs.  HHITs (with a different prefix) for other
> stuff could have other behaviors.  I would love to pursue this with you.
> 
> 
> > Is the non-transferability a requirement? Could you reword as to say that
> when
> > it is a requirement then the keys must be safeguarded in the store but
> leave it
> > open for other scenarios?
> 
> This is kind of buried in the FAA Remote ID rules for Session IDs. We
> skip the whole FAA hand waving and just make the requirement. This is
> taken from 9153 which is 'closer' to FAA (and EASA) rules.
> 
> >
> >> 4.3.  Remote ID DET as one Class of Hierarchical HITs
> >>   UAS Remote ID DET may be one of a number of uses of HHITs.  However,
> >>   it is out of the scope of the document to elaborate on other uses of
> >>   HHITs.  As such these follow-on uses need to be considered in
> >>   allocating the RAAs (Section 3.3.1) or HHIT prefix assignments
> >>   (Section 8).
> > This answers another of my questions, but then please limit your MUST to
> the
> > supported use case of DETs not for HHITs in general, to my point right
> above.
> 
> this is in the "HHITs as DETs" section, and thus I thought it would be
> limited.
> 
> 
> >
> >> 6.  Other UTM Uses of HHITs Beyond DET
> >> Please expand UTM (and add to terminology?)
> 
> I wonder at what point this got cut?  Ah, UTM is one of the BIG terms
> defined in 9153 that we point to in the beginning of Definitions.  I was
> told to remove duplicate defs.  I will expand:
> 
> UAS Traffic Management (UTM) in this first use.
> 
> >
> > 8.2.  New IANA DRIP Registry
> >
> >
> >   >   Hierarchical HIT (HHIT) Suite ID:
> >
> >   >      HHIT Suite          Value
> >
> >   You probably want an  additional column with ref to the algorithms, or
> maybe
> >   reuse either the format or registry  of RFC 8928, more below.
> 
> This mirrors 7401 HIP registry which predates 8928.
> 
> I question the value, here in this registry, to go back to where each of
> these are defined.  Other than the referenced rfcs?
> 
> >
> >> 8.4.  IANA HIP Registry Updates
> >>   EdDSA Curve Label:
> > Any way to use / extend
> > https://www.rfc-editor.org/rfc/rfc8928.html#name-crypto-type-subregistry
> > ?
> 
> No.  I have problems with that registry and do not want to conflict it
> with the goals here.
> 
> >
> >> 9.  Security Considerations
> >>   The 64-bit hash in HHITs presents a real risk of second pre-image
> >>   cryptographic hash attack Section 9.4.
> > This partially addresses another of my earlier questions.
> 
> 
> Yes.  See that I did take this to CFRG and following what we covered there.
> 
> >
> >>   However, with today's computing power, producing 2^64 EdDSA keypairs
> >>   and then generating the corresponding HHIT is economically feasible.
> > That would be 2^60, unless I miss something? and then maybe there'd be a
> way to
> > variate other fileds of the hash with the same key.
> > Then there's the post Quantum thingy. I guess it's safe to say that this
> model
> > is not post-Q resilent right?
> 
> No 2^64.  That was a error up there in Fig 1.  Thanks for catching that.
> 
> Not PQ resilient.  No viable PQC solution at this point that we can
> shoehorn into this small size dictated by other regulations.  One one
> hits the surf, we can allocate a HHSI for it.
> 
> >
> >>   The Registry service [drip-registries], through its HHIT
> >>   uniqueness enforcement, provides against forced or accidental HHIT
> >>   hash collisions.
> > When it's reachable. When it's not, there can be both impersonation and DOS
> > attacks based on the false ID.
> 
> This is where drip-auth comes in.  With its HDA-UA Broadcast Attestation
> (appdx B), a small cache of HDA HHIT/HI would provide the needed protection.
> 
> We specifically considered how this would work with no Internet access
> to the Observer.  Either because they were in some National Park with no
> access, or a natural disaster with everything down, we designed for an
> approach that worked 'offline'.
> 
> But you have to get into the weeds.  drip-rid only sets the stage.
> 
> 
> >
> >> 9.3.  Privacy Considerations
> >>   There is no expectation of privacy for DETs; it is not part of the
> >>   privacy normative requirements listed in, Section 4.3.1, of
> >>   [RFC9153].
> > This addresses another of my initial questions.
> 
> This is over a broadcast media.  What are we suppose to do?  Totally
> blind it?  FAA (and those they proxy for) would not allow this. Well
> they do provide for UUID usage, but then this is supposed to only be
> used for where it can publicly be linked.
> 
> 
> >
> >>   DETs are broadcast in the clear over the open air via
> >>   Bluetooth and Wi-Fi.
> > So L2 security when present still protects the ID but not MAC, correct?
> 
> Show me an L2 security over a broadcast media.  Yes we kind of did it
> for 802.1AE, but then it is a small group that shares the key. Here it
> has to be for anyone listening and that means no real security.
> 
> And MAC is always exposed.  There are claims of L1 security, but those
> are really special cases for P2P links.
> 
> 
> >
> >> 9.4.  Collision Risks with DETs
> >>    The 64-bit hash size does have an increased risk of collisions over
> >>    the 96-bit hash size used for the other HIT Suites.
> > Is that true also for voluntary collisions (brute force) ?
> 
> ?  that is what this section is about.  Straight probability stuff. What
> can be brute forced?
> 
> 
> >> 10.2.  Informative References
> >                unmanned-aerial-systems-serial-numbers>.
> 
> 
> I do not get this question.  What do you want to know?  xml2rfc wraps
> the URL this way.
> 
> >
> >>   [drip-architecture]
> > Shouldn't be normative?
> >
> >>   [drip-authentication]
> > Same, and then for registries?
> 
> Answered by wg chair.
> 
> I hope this helps and I look forward to your responses.
> 
> Bob