Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review
Adam Wiethuechter <adam.wiethuechter@axenterprize.com> Tue, 28 February 2023 20:17 UTC
Return-Path: <adam.wiethuechter@axenterprize.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB9C1527A6; Tue, 28 Feb 2023 12:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.onmicrosoft.com
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 B5jVfh9inUrK; Tue, 28 Feb 2023 12:17:13 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5b::71a]) (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 8D271C1524C8; Tue, 28 Feb 2023 12:17:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oeigbvEywGXqQJXcu4xtMMmYknudSVBFhuTkyH/2yN6CgAfVovuggUiGU7+ekd3m/WSd34VpS8s6hlTmhpiTsJ0EDGpv4aVdhk1HuaKDP9hY/1XlX5bpjYu2io0zS+xd6Jgcgf1NGCgxPNGg/+Q6E3iXsduuAfe+OnVdAi9pYcujnzWlq0k+BOq593Z6MmKS7by8SCT5oqDxJDUcHC6P4xdNaXn/vBYHtqsS4i+6b5svhkTOpr6t2iTUMfDNLUtZOmcEWVPpg/DXanLfztddYjDb245mkGUyosl/Mmg5I4PkaZuSpndKETYyX2vW9aehGwoqJFBdRwbh5ADnkfFRkg==
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=hF5jnh4MirM7YrsJE/Ttq/zrmtx8SF8LMArdZDV9PyY=; b=LvP9qFvSLOPBcT3xpXT/ywEoqBDwJq4MgCxABRC6+EuvjXKx26vH6nMBoGd0juHSif/G08NGK9aiBZPvpdwXMJUIF925stlJrJmrVVVAIhq6dNDsj0hSVyzRzw1COtRr65kX7PTcmvpDX+zsFLv0eJ4KEEWfcyHXS56uCQ/FoNs0RFqDPLx9AnSR4NiI8pO9mMF6OjVe/SXwm6elK7pTkYKapxlr+wBQwUTjt2IdsnJ7zAP4Q+LkF7QiYmIaIU49jIvh+rKWRr8wKpRtEz+phICN5JLW009JkxeJh8kuQ2Xb8UgrqHxa+50ptJwy0OCOgvIfReWQyZUn4K51wjjiaQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=axenterprize.com; dmarc=pass action=none header.from=axenterprize.com; dkim=pass header.d=axenterprize.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.onmicrosoft.com; s=selector1-axenterprize-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hF5jnh4MirM7YrsJE/Ttq/zrmtx8SF8LMArdZDV9PyY=; b=bWFTY8lf7q5yelHgZElyb7QqfK373EzXU3HDaqXQ0/yZzY4QncCZYkHmhjazdgR6ORCUUD13XlxRwRiEI3xygAKLjXZxImmdc9BGa20NEy5Hr8WqnO6/5i80R1UPEDhtUcUTisK9mhdZ03jAllUF92hNeI4izEvklpga1p53vRs=
Received: from SN6PR13MB2446.namprd13.prod.outlook.com (2603:10b6:805:5f::26) by PH0PR13MB5998.namprd13.prod.outlook.com (2603:10b6:510:16d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.26; Tue, 28 Feb 2023 20:17:06 +0000
Received: from SN6PR13MB2446.namprd13.prod.outlook.com ([fe80::50b5:f622:3e38:71d]) by SN6PR13MB2446.namprd13.prod.outlook.com ([fe80::50b5:f622:3e38:71d%4]) with mapi id 15.20.6134.029; Tue, 28 Feb 2023 20:17:06 +0000
From: Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
To: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "rgm@labs.htt-consult.com" <rgm@labs.htt-consult.com>, Stu Card <stu.card@axenterprize.com>, "gurtov@acm.org" <gurtov@acm.org>
CC: "drip-ads@ietf.org" <drip-ads@ietf.org>, "drip-chairs@ietf.org" <drip-chairs@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "evyncke@cisco.com" <evyncke@cisco.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review
Thread-Index: AQHZSj5vsaoM7314m0ezsUXGK/AXVq7kx+zI
Date: Tue, 28 Feb 2023 20:17:06 +0000
Message-ID: <SN6PR13MB24469FBCF78CBC98D483B84188AC9@SN6PR13MB2446.namprd13.prod.outlook.com>
References: <20230226235951.6AFDE84D2D@rfcpa.amsl.com>
In-Reply-To: <20230226235951.6AFDE84D2D@rfcpa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=axenterprize.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR13MB2446:EE_|PH0PR13MB5998:EE_
x-ms-office365-filtering-correlation-id: dd0285da-124d-4dbe-84d7-08db19c8c334
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ATm1ULHzOrU/2NmwpagR3ssN+7y2vSA3vzVxMcquSxs+NGGN3oOaYbAJ8cjrUBO4m+KVc0iBQ3oQWIv294obJtlyXhITFWjLqx40SUkIL8MZv1IORsTnV6trI7RQ6/cCpL7XTMVxevMNUOn1Uc+gdebwSUqGZu2MFF2Ky27udgXY/VGWoT7pyFbYEUibnPNdsXOwxgoMSp96GlCXJHqADG0WHayHwKKXODxHhWAXhdJo5/3dXncdSJLjK12Sy4cSrnGLpjQfactY6bTmqtmrSdWn4qSEROF6sGQrvXuTLqi9gkpFljC30AA3doZiHdfqMB3Y9MzAxhgt5haEGHqzeSCU7zo7FQfNSp7boeCnFmQrwIYBjh8cSvHJgeLm1wCgh7sCgoPIDzn1fDgypNqBL1fu5rYXrVFfC2y5yNeCub6JHIidKk1uaugIw2e1pmLba1dIsY2cl1foHQjma3nM37e9lkBx+vCIOk18e/Pg08xT8eUQ+plN3Z5V5Shac3zUHOZkxmC2jk11yoSKFMy/WNoStPJRhVFNQM4ODkGAl5RA7JrwsKOLuF7LFzdUVEI8Whe35kxW0aGxNk2sJ7Z8xhAj9pUf69QQoP+HHpEa4Oq414CF1Gya/ohWA7dwmksnVnmpSJqYKJxaPQt8av2Brbn16YpiGA59CCHvLy8Teb44l0O4izHpW9mpHnySLCncikVUGTCrFImS29vqj/Z7RTRHLu0IadXrUl+jOh3ckQ0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2446.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(366004)(396003)(136003)(376002)(346002)(39830400003)(451199018)(19627405001)(66446008)(8676002)(64756008)(41300700001)(8936002)(4326008)(66476007)(66946007)(76116006)(52536014)(5660300002)(66556008)(30864003)(2906002)(21615005)(44832011)(38100700002)(86362001)(166002)(122000001)(38070700005)(33656002)(966005)(91956017)(316002)(478600001)(7696005)(71200400001)(55016003)(110136005)(54906003)(6506007)(53546011)(186003)(83380400001)(26005)(9686003)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: bBhzHCHWKjOxxMk5gZ+A5ubB3Y8j/0B0EYCf8S9YL9jD3Mwm+Kg7EJy0BU9vKRCl1bfCUItDzT8YaUwte1WFvgmpC62kCZwmxEDOujQ4xbiVJHrxH/AOLp9qEiyhBUJNIucrlufrhytDclZfFn19P9hZQLL8lg0A0Hi6/IuzSKBPDN0hudrAV5Llj4MkBIaYl5oyuy9TlDh3CW+TAvlc7Ho7BJP91nbkPrmllArKUax2nAE5M5dXay1/xBMaWod5OzySHbrm01EG/lATezwYwUSHYJzxvXICGGYLOqPcIvc1BDUDulZKeSAW5bj6LDabPUDf+tmZUXoFu6ohZc9oChibZPKMbh+fPZsR8PlDkcfhaz3xWP8H1gxeY/aaoy0dQ//T0IO/e92D9YTAxcWoPJs9IZ0CjrOYuSnmvXsnXVYEsH2q9E+MqYZJJEHLgv3YewSnQRXG9M2eHN+aJdpMLzNCgN1jL7T5gcZy5wn6TbS4QZvtZh6nQ+GTt4Wvdf0E1ep9jj7da4SKH0V8/VayY2jtWvrXE+r82VUE2AGvd05bIVzjmhOtOwmMpx7dMm4km+EytD3KAi0JoyBbJwMU895S4vKW7pA/Xm1drJoT8+OdrJvQV4nuBX/b1UDdT3r5Bon6Pn6rlnDhVQkjjpOWjUORx4dRWRlCkj/mX05j9XzYQUXpYVECdWJ75sHmpmF073/ZUv2mwWWlRjso5K/oM88dFaMdWaPDtQY4o9PNwhF0b+qyR8X1YfHKqZvFM9Q8dYSM7rfDPSCT8xfV9jC1CBoHXDbEnvZqTZ3JhelaT67VGhePsexXN5qR7o+4jZAYzpbDrRAPW4wKkjSXgNidbUw6cXOpiU/Nw/jTapcONuYAWp9Mo8LTOuXrssd7gUKn86qC/17EjpulEa05lg4Lsfmsrwo4AKnUneEPIMddAH8SQtNNmIZajHm6xqJ7kdHY4Lhu28Td5fVgvDkQf85M0Rb73ujrIAF7whkmK4OfOY+1DpoW27X44NVT+KnKObE63pmTs4uXyWOVf49LG2RWi1tvS/w20TMpkHYluZyYF5K3xHBiE3+8ou8KlqW47wWm7TVXhbhJUjworVddzIR31mg5EWj8Uh7HjebM2QCkytaqPGzBm9aARdnaNA5EQ5Bv+iTX9o41Mvae1s/5NEwyXTjO58Ce6xW78HyCDEHs3uXygXGVxtIYX8WEHIARIyYZZ4jQMmw4Xog98t5xcEn4Lc1TRktxNd5W2DaZw67wv+LbTtvSm5uE5Z7pPabvUC8u3QDzP6SE5EgvIfeoC+LJMrHp8gBXGG/SOIEFncJzyRnFUPHsZHYiJHlQJbbwXQYwyvCYji+CQ2MVnYA5YgG/gr5K3SG6sP+m8jM95j8oQJGhLeqf5X77QnceVFwZ0Rv3S+HV4LLWaML8mWwFY/GV3X92qy5cTDXnhf4+dbLGBw2bsVq2bKGx1Eia6r5vnZ9Q2BcmD+XZI8Dpx0cTntPM6WabMSnitOTsE9LJzh6dVb/z3SkrNv+Y/PuxiO4vronxlvKQOo5KtjPhtdmszFxMNtkG1uxORH3eByk5cRhusUS2SHqJEfDUnZwc1hZsB+dJjbFW38b/vWTiaZTQ6G9qf3XiTl+kC+aSTH1hiMKA860=
Content-Type: multipart/alternative; boundary="_000_SN6PR13MB24469FBCF78CBC98D483B84188AC9SN6PR13MB2446namp_"
MIME-Version: 1.0
X-OriginatorOrg: axenterprize.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2446.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd0285da-124d-4dbe-84d7-08db19c8c334
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2023 20:17:06.1897 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 00ad0178-ead0-441e-96ff-0c72baf3a6fa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: y3JQzK01Mxl7afXPkGEAN9GnsWnw2BC/72JfLrfq1xEmBpRd6IeSXnqDMwlg3wed0hNBsDEMzMR2gFxu3otnAP8rgrLpe9JXFzbWZUNXL3BwUXLPIugLBJ4/6lj9g+Lc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR13MB5998
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/ujH7SelrTQIrsRIcNMRdXKKFAOA>
Subject: Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2023 20:17:17 -0000
One nit I found as reviewing with Stu. Section: Appendix B OLD: At this writing ICAO has 273 member "States", each may want to control RID assignment within its National Air Space (NAS). NEW: At this writing ICAO has 193 member "States", each may want to control RID assignment within its National Air Space (NAS). Source: https://www.icao.int/MemberStates/Member%20States.English.pdf -------- 73, Adam T. Wiethuechter Software Engineer; AX Enterprize, LLC ________________________________ From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> Sent: Sunday, February 26, 2023 6:59 PM To: rgm@labs.htt-consult.com <rgm@labs.htt-consult.com>; Stu Card <stu.card@axenterprize.com>; Adam Wiethuechter <adam.wiethuechter@axenterprize.com>; gurtov@acm.org <gurtov@acm.org> Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>; drip-ads@ietf.org <drip-ads@ietf.org>; drip-chairs@ietf.org <drip-chairs@ietf.org>; mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>; evyncke@cisco.com <evyncke@cisco.com>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] For readability, we suggest the following update: Original: This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). Perhaps: This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use as an Unmanned Aircraft System Remote Identification (UAS RID) and tracking. --> 2) <!-- [rfced] Does "This" refer to this document or RFC 9153 (i.e., is RFC 9153 the foundational document)? Original: Drone Remote ID Protocol (DRIP) Requirements [RFC9153] describe an Unmanned Aircraft System Remote ID (UAS ID) as unique (ID-4), non- spoofable (ID-5), and identify a registry where the ID is listed (ID- 2); all within a 19-character identifier (ID-1). This DRIP foundational document (i.e., all else in DRIP enables or uses it) describes (per Section 3 of [drip-architecture]) the use of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the UAS Remote ID. --> 3) <!-- [rfced] May we update this text as follows? Otherwise, please clarify. Original: HHIT will be used when covering the technology, and DET for their context within UAS RID. Perhaps: HHIT will be used when covering the technology, and DET will be used in the context of UAS RID. --> 4) <!-- [rfced] May we replace instances of "Hierarchical HITs" with "HHITs" throughout once the abbreviated form has been introduced? For example: Hierarchical HITs provide ... Hierarchical HITs are valid, ... Hierarchy ID (HID) ... --> 5) <!-- [rfced] The closing parentheis is missing. Please confirm the placement of the closing parenthesis. Original: This contrasts with using general identifiers (e.g., a Universally Unique IDentifiers (UUID) [RFC4122] or device serial numbers as the subject in an X.509 [RFC5280] certificate. In either case, there can be no unique proof of ownership/registration. Current: This contrasts with using general identifiers (e.g., a Universally Unique IDentifiers (UUID) [RFC4122]) or device serial numbers as the subject in an X.509 [RFC5280] certificate. In either case, there can be no unique proof of ownership/registration. --> 6) <!-- [rfced] For readability, we recommend the following update. Original: The document includes a set of algorithms with a guidance on the ones that are recommended to be supported by implementations. Suggested: The document includes a set of algorithms and recommends the ones that should be supported by implementations. --> 7) <!-- [rfced] The XML file includes author comments. We have added [author] to these comments to clearly differentiate them from questions inserted by the RFC Production Center. Please review and let us know if any updates are needed; otherwise, these will be deleted. --> 8) <!-- [rfced] Does this text mean the protocol upon which HI, HIT and HHIT are based? If this is correct, perhpas the reference should appear after "Host Identity Protocol (HIP)"? Original: HIP (Host Identity Protocol) The origin [RFC7401] of HI, HIT, and HHIT. Perhaps: Host Identity Protocol (HIP) [RFC7401]: The origin of HI, HIT, and HHIT. --> 9) <!-- [rfced] Please review instances of <artwork> in the XML and let us know if any should instead be <sourcecode>. If <sourcecode, please consider wheter the "type" attribute should be set (see https://www.rfc-editor.org/materials/sourcecode-types.txt). If the list does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. --> 10) <!-- [rfced] For clarity, we suggest not using "4/8-bit". Does this mean, "4 and 8 bit"? May we update this text as follows? Original: These are a superset of the 4/8-bit HIT Suite ID as defined in Section 5.2.10 of [RFC7401]. Perhaps: These are a superset of the 4-bit and 8-bit HIT Suite IDs as defined in Section 5.2.10 of [RFC7401]. --> 11) <!-- [rfced] For readability, please consider whether this update correctly conveys the intended meaning. Original: The rationale for the 14/14 HID split is described in Appendix B. Perhaps: The rationale for splitting the HID into two 14-bit domains is described in Appendix B. --> 12) <!-- [rfced] Will "zone tree" be clear for the reader? In addition, is "in the actual zone tree" correct (as opposed to, for example, "regarding the actual zone tree" )? Original: Thus further thought will be needed in the actual zone tree and registration process [drip-registries]. --> 13) <!-- [rfced] May we update this to specify that the EdDSA HI uses the value assigned per [ipseckey-eddsa] for IPSECKEY RR encoding? Original: The new EdDSA HI uses [ipseckey-eddsa] for the IPSECKEY RR encoding. Suggested: The new EdDSA HI uses value assigned per [ipseckey-eddsa] for IPSECKEY RR encoding. --> 14) <!-- [rfced] Is NIST SP 800-185 the reference for cSHAKE? May we update text as follows? Original: * Use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the hashing function. Perhaps: * the use of cSHAKE [NIST.SP.800-185] for the hashing function. --> 15) <!-- [rfced] We have updated [TBC_DRIP_REGISTRY] to point to the "Hierarchical HIT (HHIT) Suite ID" registry <https://www.iana.org/assignments/drip> and added an informative reference. Please review and let us know if any updates are needed. Original: ... When used for HHIT generation this is the HHIT Suite ID [TBC_DRIP_REGISTRY]. Note to the RFC Editor: Please replace [TBC_DRIP_REGISTRY] with the pointer to the IANA registry created in Section 8.2. --> 16) <!-- [rfced] In section 3.5.1, is this formatting update correct? Is this line intended to appear as part of the definition list? We have currently formatted it as a separate item (i.e., not part of the list). Please review. Original: Sizeof(p + n + o + m) 128 bits --> 17) <!-- [rfced] It is not clear to us what "call for this update" means. Please review. follows? Original: The cSHAKE function call for this update is: Perhaps: The update for this cSHAKE function is as follows: --> 18) <!-- [rfced] Please confirm that 'UAS ID type 4, "Specific Session ID (SSI)"' is not an IANA-registered value. In addition, we are unable to verify SSI 1 and SSI 2. We do not see related actions in the IANA Considerations section, and we are unable to access [F3411-22a] (https://www.astm.org/f3411-22a.html)? Please review and let us know if any updates are needed. Original: The ASTM Standard Specification for Remote ID and Tracking [F3411-22a] adds support for DETs. This is only available via the new UAS ID type 4, "Specific Session ID (SSI)". ... SSI 1 IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID. SSI 2 3GPP - IEEE 1609.2-2016 HashedID8 --> 19) <!-- [rfced] Note that we updated the link for Section 5 to go directly to this line of <artwork>. Please let us know if any corrections are needed. Section 5: 2001:30:280:1405:a3ad:1952:ad0:a69e Section 4.2: Original: Using the sample DET from Section 5 that is for HDA=20 under RAA=10 and having the ICAO CTA MFR Code of 8653, the 20-character CTA 2063-A Serial Number would be: 8653F02T7B8RA85D19LX --> 20) <!-- [rfced] We are having trouble parsing "88-byte self-proof evidence". If possible, please clarify. Original: The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an 88-byte self-proof evidence (timestamp, HHIT, and signature of these) to provide proof to Observers of Remote ID ownership (GEN-1 in [RFC9153]). --> 21) <!-- [rfced] Please review the questions below regarding this text: Original: There are two approaches for storing and retrieving DETs using DNS. The following are examples of how this may be done. This will serve as guidance to the actual deployment of DETs in DNS. However, this document does not provide a recommendation. Further DNS-related considerations are covered in [drip-registries]. * As FQDNs, for example, "20010030.hhit.arpa.". * Reverse DNS lookups as IPv6 addresses per [RFC8005]. a) Please confirm that these are examples, and not the two approaches. b) For clarity, may we update the text to read: However, this document does not provide a recommendation about which approach to use. --> 22) <!-- [rfced] Is the HDA providing HHIT with a detailed response or should this read "the detailed HHIT response"? Please review. Original: The HDA SHOULD provide DNS service for its zone and provide the HHIT detail response. --> 23) <!-- [rfced] Does "could be to" mean "result in"? Are the two periods intentional? A DET reverse lookup could be to: a69e.0ad0.1952.a3ad.1405.0280.20.10.20010030.hhit.arpa.. --> 24) <!-- [rfced] Section 8.1: Please note that we updated the registration entry to match what appears in the IANA registry. Please let us know if any updates are needed. --> 25) <!-- [rfced] Section 8.2 seems to create the "Drone Remote ID Protocol" group of registries, which contains the "Hierarchical HIT (HHIT) Prefixes" and "Hierarchical HIT (HHIT) Suite ID" registries. Is it correct that the text about expert review only applies to "Hierarchical HIT (HHIT) Prefixes", as the registration procedure for "Hierarchical HIT (HHIT) Suite ID" is IETF Review? If this is correct, may we move the text describing criteria for the designated expert to appear after the table 8, to make it more clear that it applies to the "Hierarchical HIT (HHIT) Prefixes" registry? Would it be helpful to divide 8.2 into the following sections: 8.2.1. Hierarchical HIT (HHIT) Prefixes 8.2.2. Hierarchical HIT (HHIT) Suite IDs Note that we have removed this sentence entirely, as we believe it is common practice for IANA to have at least two experts for a given registry. Please let us know if you prefer otherwise. Original: It is suggested that multiple designated experts be appointed for registry change requests. --> 26) <!-- [rfced] Section 8.2: Should the title for "Hierarchical HIT (HHIT) Suite ID" be plural (i.e., "Hierarchical a HIT (HHIT) Suite IDs")? --> 27) <!-- [rfced] Section 8.2: <https://www.iana.org/assignments/drip> lists this document as the refernece for value 0 (Reserved). We have updated the table to match. We note that the "HIT Suite ID" references RFC 7401 for value 0 (Reserved), but this seems ok since it is outside of the 1-31 range. In addition, please note that the "HIT Suite ID" registry seems to have values 1-15, but the text below indicates values 1-31 should match "HIT Suite IDs" registrations. Please review and let usk now if any updates are needed. Original: HHIT Suite Value Reference RESERVED 0 ... The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be replicated as HIT Suite IDs (Section 8.4) as is TBD3 here. Note that similar text appaers in Section 8.4: Original: The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here. --> 28) <!-- [rfced] Should this document be listed as a reference for the full "CGA Extension Type Tags" registry, or just the entry for "0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40"? If both, perhaps: Original: This document requests that this document be added to the reference field for the "CGA Extension Type Tags" registry [IANA-CGA], where IANA registers the following Context ID: Perhaps: This document has been added as a reference for the "CGA Extension Type Tags" registry [IANA-CGA]. IANA has registered the following Context ID in this registry: --> 29) <!-- [rfced] Section 8.3: We converted the registration text into a table for clarity and to better align with what appears in the IANA registry.. Please let us know this causes any concern. Original: Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 [This] Current: +===========================================+===========+ | CGA Type Tag | Reference | +===========================================+===========+ | 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 | RFC 9374 | --> 30) <!-- [rfced] We are having trouble parsing "studies of hash size to cryptographic hash attacks". Does this mean "studies of hash size in relation to cryptographic hash attacks"? Original: There are no known (to the authors) studies of hash size to cryptographic hash attacks. --> 31) <!-- [rfced] What is being signed - the object or the HHIT? Original: Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object containing the HHIT and signed by the HI private key of the HDA such as detailed in [drip-authentication]. Perhaps: Another mitigation of HHIT hijacking is when the HI owner (UA) supplies an object containing the HHIT that is signed by the HI private key of the HDA as detailed in [drip-authentication]. --> 32) <!-- [rfced] For readability, please consider whether the suggested text correctly conveys the intended meaning. Original: Collision resistance (more important that it implied second-preimage resistance) makes it statistically challenging to attacks. Perhaps: Collision resistance (and more importantly, the implied second-preimage resistance) makes attacks statistically challenging. --> 33) <!-- [rfced] To avoid awkward hyphenation and for clarity, may we update this sentence as follows? Original: HHITs contain the ID for the cryptographic suite used in its creation, a future post quantum computing safe algorithm that fits the Remote ID constraints may readily be added. Suggested: HHITs contain the ID for the cryptographic suite used in its creation, a future algorithm that is safe for post-quantum computing that fits the Remote ID constraints may readily be added. --> 34) <!-- [rfced] May we update this sentence for readability? Original: The best that might be done within this Basic ID Message is 4 bytes truncated from a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is 16). Suggested: Truncating 4 bytes from a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is 16) within this Basic ID Message is the best that can be done. --> 35) <!-- [rfced] We are having trouble parsing this sentence. Does "the observer can see the UA or that information is validated" mean that the "observer can see that the UA or the information in question is validated"? Please clarify. Original: Proof of UA transmission comes when the Authentication Message includes proofs for the ASTM Location/Vector Message (Msg Type 0x1) and the observer can see the UA or that information is validated by ground multilateration. --> 36) <!-- [rfced] Please confirm that MAC refers to Media Access Control. For example: Further, the MAC address of the wireless interface used for Remote ID broadcasts are a target for UA operation aggregation that may not be mitigated through MAC address randomization. --> 37) <!-- [rfced] Is "historically tracking" correct? We wonder if "tracking the history of the UA's activity" is meant? Original: Finally, it is not adequate to simply change the DET and MAC for a UA per operation to defeat historically tracking a UA's activity. --> 38) <!-- [rfced] Please consider whether the suggested update improves readability and maintains the intended meaning. Original: UA/GCS binding is complicated with changing MAC addresses; historically UAS design assumed these to be "forever" and made setup a one-time process. Perhaps: UA/GCS binding is complicated because of the changing MAC addresses; historically, UAS design assumed the ddresses to be static "forever" and made setup a one-time process. --> 39) <!-- [rfced] Does "changing the DET" trigger other changes, or it is the beginning of a set of changes? Original: Simply changing the DET only starts the changes that need to be implemented. Perhaps: Changing the DET is only the start of the changes that need to be implemented. --> 40) <!-- [rfced] Does "(or similar behaving)" mean "(or a similar purpose)"? And, please consider whether "will take years of deployment experience" should be "deployment experience will take years". Original: Perhaps a single RAA providing HDAs for delivery service (or similar behaving) UAS could 'get by' with a 2048 HDA space (11-bits). ... But as this is speculation, and it will take years of deployment experience, a 14-bit HDA space has been selected. Perhaps: Perhaps a single RAA providing HDAs for delivery service (or a similar purpose) UAS could 'get by' with a 2048 HDA space (11-bits). ... However, as this is speculation and deployment experience will take years, a 14-bit HDA space has been selected. --> 41) <!-- [rfced] We are having trouble parsing this sentence. Please consider whether the suggested update conveys the intended meaning. Otherwise, please clarify. Original: The HDA space is large enough that some to use part for government needs as stated above and for small commercial needs. Or the State may use a separate, consecutive RAA for commercial users. Perhaps: The HDA space is large enough that a portion may be used for government needs as stated above and small commercial needs. Alternatively, the State may use a separate, consecutive RAA for commercial users. --> 42) <!-- [rfced] Will "nibbled fields" be commonly understood by readers? Original: The DET upper 64 bits appear to be oddly constructed from nibbled fields, when typically seen in 8-bit representations. --> 43) <!-- [rfced] Does "leaving remaining RAA and HDA combined to" mean "which leaves the remaining RAA and HDA to combine to"? Original: The left most 4 bits of the RAA, all zeros, combine with the prefix to form 2001:0030:, leaving remaining RAA and HDA combined to: --> 44) <!-- [rfced] Does "does not lend to using" mean "is not well suited for using"? Original: The alphabet used in CTA 2063-A Serial Number does not lend to using any published Base32 encoding scheme. --> 45) <!-- [rfced] Would you like to make use of <sup> for superscript in this document? You can see how it looks here: https://www.rfc-editor.org/authors/rfc9374-sup.html https://www.rfc-editor.org/authors/rfc9374-sup.pdf https://www.rfc-editor.org/authors/rfc9374-sup.txt Note: In the HTML and PDF, it appears as superscript. In the text output, <sup> generates a^b. --> 46) <!-- [rfced] Please review the following regarding terminology: a) Throughout the text, the following term appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. authentication message vs Authentication Message b) Note that instances of "IPV6" have been updated to "IPv6" (lowercase v). c) In addition, note that we have used the following articles. Please let us know if any corrections are needed. an HI (read "hy") an HDA (read as letters, i.e., an eche dee aye) a HIP (read as the word hip) a HIT (read as the word hit) a HHIT - how is this read? --> Thank you. RFC Editor On Feb 26, 2023, at 3:43 PM, rfc-editor@rfc-editor.org wrote: *****IMPORTANT***** Updated 2023/02/26 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info/). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-editor@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9374.xml https://www.rfc-editor.org/authors/rfc9374.html https://www.rfc-editor.org/authors/rfc9374.pdf https://www.rfc-editor.org/authors/rfc9374.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9374-diff.html https://www.rfc-editor.org/authors/rfc9374-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9374-xmldiff1.html The following files are provided to facilitate creation of your own diff files of the XML. Initial XMLv3 created using XMLv2 as input: https://www.rfc-editor.org/authors/rfc9374.original.v2v3.xml XMLv3 file that is a best effort to capture v3-related format updates only: https://www.rfc-editor.org/authors/rfc9374.form.xml Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9374 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9374 (draft-ietf-drip-rid-37) Title : DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) Author(s) : R. Moskowitz, S. Card, A. Wiethuechter, A. Gurtov WG Chair(s) : Daniel Migault, Mohamed Boucadair Area Director(s) : Erik Kline, Éric Vyncke
- [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-drip-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Stu Card
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Adam Wiethuechter
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Adam Wiethuechter
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Stu Card
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Stu Card
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Stu Card
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Robert Moskowitz
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Adam Wiethuechter
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Andrei Gurtov
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-d… Sandy Ginoza
- [auth48] [IANA #1268454] Re: AUTH48: RFC-to-be 93… Sabrina Tanamal via RT
- Re: [auth48] [IANA #1268454] AUTH48: RFC-to-be 93… Sandy Ginoza
- [auth48] final questions - Re: AUTH48: RFC-to-be … Alice Russo
- Re: [auth48] final questions - Re: AUTH48: RFC-to… Robert Moskowitz
- Re: [auth48] final questions - Re: AUTH48: RFC-to… Alice Russo
- Re: [auth48] final questions - Re: AUTH48: RFC-to… mohamed.boucadair
- Re: [auth48] final questions - Re: AUTH48: RFC-to… Alice Russo