drip Working Group A. Wiethuechter Internet-Draft AX Enterprize, LLC Intended status: Standards Track 4 November 2024 Expires: 8 May 2025 Means of Compliance for DRIP Entity Tags as UAS RID Identifiers draft-wiethuechter-drip-det-moc-00 Abstract This document is intended for Civil Aviation Authorities (CAAs) as a Means of Compliance (MOC) for using Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS) Remote ID (RID) identifiers. This enables Session IDs, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 May 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Wiethuechter Expires 8 May 2025 [Page 1] Internet-Draft det-moc November 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Additional Definitions . . . . . . . . . . . . . . . . . 4 3. Interactions & Responsibilities . . . . . . . . . . . . . . . 5 3.1. UAS Observers . . . . . . . . . . . . . . . . . . . . . . 5 3.2. UAS Operators . . . . . . . . . . . . . . . . . . . . . . 5 3.3. UAS Manufacturers . . . . . . . . . . . . . . . . . . . . 6 3.4. HDA Operators . . . . . . . . . . . . . . . . . . . . . . 6 3.5. RAA Operators . . . . . . . . . . . . . . . . . . . . . . 7 4. DRIP Service Options . . . . . . . . . . . . . . . . . . . . 7 5. Requirements for DIME Operation . . . . . . . . . . . . . . . 7 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Public Information Registries . . . . . . . . . . . . 7 5.1.2. Private Information Registries . . . . . . . . . . . 8 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Cross Cutting . . . . . . . . . . . . . . . . . . . . . . 8 6. Compliance Testing . . . . . . . . . . . . . . . . . . . . . 9 6.1. Registration Interface . . . . . . . . . . . . . . . . . 10 6.2. Public Query Interface . . . . . . . . . . . . . . . . . 10 6.3. Private Query Interface . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8.1. DETs as a Locator . . . . . . . . . . . . . . . . . . . . 11 9. Privacy & Transparency Considerations . . . . . . . . . . . . 11 9.1. DETs as Session ID and Authentication Key ID . . . . . . 11 9.2. Selective Encryption . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. HID Abbreviation . . . . . . . . . . . . . . . . . . 14 Appendix B. Compliance Submission Forms . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction 1.1. Purpose This document is written to reference other documents, thus acting as an introduction for Civil Aviation Authorities (CAAs) and their Operators attempting to comply within a given jurisdiction. A CAA MAY override any requirement in this document, but MUST provide the reason and an alternative for their operators to implement. This document offers technical options, with recommendations of defaults Wiethuechter Expires 8 May 2025 [Page 2] Internet-Draft det-moc November 2024 for international interoperability. 1.2. Background A registry function including Hierarchical Host Identity Tag (HHIT) Domain Authority (HDA) is required to support Session IDs that can be used by CAAs and other lawfully authorized parties to look up essential safety and security information associated with UAS and their Operators. In the Unmanned Aerial System (UAS) Traffic Management (UTM) context, it is expected that the HDA function will be provided by each UAS Service Supplier (USS). This can be in-house or out-sourced to a service bureau more specialized in cryptographically verifiable identifiers usable to access data and systems on networks. Outside the UTM context, each Operator must still obtain this function from some provider. The HDA function also can support other services related to Session IDs. The DRIP Entity Tag (DET) can act as a Session ID and/or Authentication Key ID, thus HDA functionality in this document assumes both are being provided to registrants (see Section 9.1 for more details). The use of Authentication is mandated in some (e.g. Japan) but not all regions. Each DET is tied to a longer term identifier by its HDA. Typically this identifier is expected to be the UAS Serial Number, however a CAA MAY choose another long term identifier of significance to them. 1.3. Scope Any entity involved in UAS Broadcast RID as per this document: * if that entity uses a Session ID (some participating entities, e.g. HDAs, may not have Session IDs), MUST use a DET for that Session ID. * if that entity participates in DRIP protocol interactions (even if not needing a Session ID), MUST use a DET for the DRIP public key ID. * if that entity requires a strongly cryptographically verifiable IP compatible identifier, MAY use a DET for any other legal purpose. * SHOULD NOT use DET as a locator in physical or logical space (e.g. as a globally routable IPv6 address outside of an overlay network). See Section 8.1 for further details. Wiethuechter Expires 8 May 2025 [Page 3] Internet-Draft det-moc November 2024 The archetypal case is a UAS for which the DET serves as both the UAS ID (e.g. in the ASTM [F3411] Basic ID Message as a Type 4, Subtype 1 Specific Session ID) and the Authentication Key ID. DRIP builds upon existing UAS RID standards (ASTM [F3411]) and baseline Means of Compliance (ASTM [F3586]). This document acts as a further Means of Compliance for DETs to be used as Session IDs and/or Authentication Key IDs. This document is intended to be internationally applicable but at the time of first writing the authors have only confirmed compatibility with ASTM [F3586] (and thus US FAA rules). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Additional Definitions This document makes use of terms (PII, USS, etc.) defined in [RFC9153], [RFC9434] and [RFC9374]. For convenience of the reader, some of the major definitions are restated here. TODO: find good accurate definitions of these terms & order them UAS RID identifier: a term used in this document to encompass the use of a DET to be used as any combination of the following: UAS Specific Session ID, Authentication Key ID and Encryption Key ID. DRIP Identity Management Entity (DIME): Originally defined in [RFC9434] and expanded technically in [DET-DNS]. An entity providing registrar and registry services specifically for DETs. Attestation: i.e. secure boot of a device Authentication: of the individual (essential) Authorization: the admin action of defining roles and what access is permitted for them & the subsequent reference to these roles in policy based determination to grant or deny specific access requests Access Control: i.e. zero trust. Fine grained near real time access control Wiethuechter Expires 8 May 2025 [Page 4] Internet-Draft det-moc November 2024 Attribution: every action needs to attributable to who took it Accounting: resource use MUST be tracked Audit: look back at any of the above after the fact 3. Interactions & Responsibilities This section outlines the various players in the ecosystem. For each, it outlines relevant motivations for using DRIP, as well as the interactions and responsibilities they have in doing so. 3.1. UAS Observers An Observer has many motivations for detecting Broadcast RID. Regardless of their motivation the authenticity of the data presented is important for them to make decisions on their next actions. This is accomplished by the use of Authentication of the Broadcast RID, something DRIP provides. Observers also may need additional information, beyond what is sent over Broadcast RID. While the use of a Session ID provides a level of privacy, the use of DRIP allows this privacy while also enabling authorized queries for additional data. An Observer device is expected to be able to process messages compliant with [F3586] and [F3411] Broadcast RID including: 1. Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag). The UAS ID SHOULD be displayed either in the style of an IPv6 address per [RFC5952] or as described in Appendix A. 2. Authentication Messages (Message Type 0x2), Authentication Type 0x5 (Specific Authentication Method (SAM)), SAM Types 0x01 (DRIP Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest) and optionally 0x04 (DRIP Frame). The details of these SAM Types are described in [RFC9575]. Observer devices MUST follow the requirements of Section 6.4.2 of [RFC9575]. Appendix A of [RFC9575] is RECOMMENDED for visualization of the trustworthiness assessment. 3.2. UAS Operators UAS Operators may want to protect the privacy of their details (such as Operator Location) and their reputation. Reputation can be gained or lost with observation and reports of behavior backed by Authentication. They MAY decide for which UAS RID identifier purposes they will use DETs. This choice may be constrained by the jurisdiction's RID regulations. Wiethuechter Expires 8 May 2025 [Page 5] Internet-Draft det-moc November 2024 Author: move to Definitions: whether to use DRIP for an Authentication Key ID only, Single Use Session ID only, or both. The last of these is the natural approach providing the greatest benefits and thus the primary focus of this document. 3.3. UAS Manufacturers Manufacturers typically wish to maintain good reputation of their brands and are often driven by market forces. Such forces include requirements and preferences of both UAS Observers and Operators. To satisfy CAA requirements, a UA MUST transmit whatever [F3411] messages are needed to carry at least the minimal elements of information required by the regulator. In the US, under the current FAA RID rule, these are Basic ID, Location/Vector, and System as specified in [F3586]. If the content of these messages is to be trusted, the UA MUST also sign those messages, using the DRIP Wrapper and/or DRIP Manifest methods, as described in [RFC9575]. Author: add reference to US RID rule The UAS MUST provide mechanisms and interfaces to enable DET support for UAS Operator selected purposes. For DRIP this requires at minimum the UAS Operator to be able to select DRIP options and start the process of generating and registering a DET with a selected HDA. 3.4. HDA Operators An HDA Operator must fullfil the requirements of their jurisdiction. They must also satisfy the desires of UAS Operators. The HDA MUST provide, upon successful registration of a DET, the four Broadcast Endorsement objects for use in [RFC9575]. These are: * Broadcast Endorsement: RAA:A on RAA:I * Broadcast Endorsement: RAA:I on HDA:A * Broadcast Endorsement: HDA:A on HDA:I * Broadcast Endorsement: HDA:I on Registrant The HDA must also place certain essential information into the Internet Domain Name System (DNS) and maintain that information as operations are activated, completed, etc. All the information to be placed into the DNS is public as it is either needed to make the DET based systems work or because it is a high-availability replica of information transmitted in clear-text via Broadcast RID. The DNS Wiethuechter Expires 8 May 2025 [Page 6] Internet-Draft det-moc November 2024 records also MUST point to the private registry in which additional information, required by the HDA/USS itself or the CAA, must be placed and maintained, for query by authorized parties only. 3.5. RAA Operators RAAs in this document are scoped to be operated by a State. Each State is allocated four RAAs, and may decide on their usage. Each RAA MUST register HDAs within its scope. Each RAA MUST provide both widely supported "long form" X.509 certificates and DRIP- specific "short form" endorsements of its HDAs. The RAA MAY provide services to HDAs for verification of data pertaining to UAS Operators. For example an HDA registering a UAS Session ID may query the RAA to verify a previously RAA-registered UAS Serial Number. The RAA Operator MUST obtain valid DNS delegation. See Section 7 for more details. 4. DRIP Service Options TODO: selection options matrix 5. Requirements for DIME Operation The requirements below apply to both RAA and HDA operators with a focus on how HDA operators provide registration and related services for their clients (i.e. UAS Operators and their UAS). 5.1. Query A DIME has two query interfaces it MUST support. One interface is used for public information query and another (identified and using data found via public queries) is for private information. 5.1.1. Public Information Registries The information found in these registries has been designated as public (explicitly or implicitly) by cognizant authority and/or the information owner. Such information includes public cryptographic keys needed for authentication in [RFC9575], static Broadcast RID data and trustworthy pointers to additional information. These registries are Authoritative Name Servers of DNS. See [DET-DNS] for operational requirements, query mechanism and response models. Wiethuechter Expires 8 May 2025 [Page 7] Internet-Draft det-moc November 2024 5.1.2. Private Information Registries The information found in these registries is considered Personally Identifiable Information (PII) and/or is stored for potential future audit of registration. Private information queries MUST follow [DET-DIFF-ACCESS]. This specifies the use of Registration Data Access Protocol (RDAP) data models and query formats as the primary query mechanisms. The specific access control policies are to be defined by the CAA. A CAA MAY require additional query mechanisms for their jurisdiction. 5.2. Registration There are several registration functions essential to achieving the purposes to which this document is directed. Likewise there are several viable technical approaches to performing these functions. The only approaches fully specified in [DET-REGISTRATION] are the Constrained Application Protocol (CoAP) [RFC7252] and/or Concise Binary Object Representation (CBOR) Web Tokens (CWT) [RFC8392]. DRIP does NOT provide protection against incorrect (e.g. fraudulent) data entered during registration or asserted subsequently. DRIP does protect against alteration (intentional or unintentional) of data subsequent to its assertion by the cryptographic signer. The signer might be the proximate sender (e.g. UA transmitting Broadcast RID) or might be an attestor far away and long ago (e.g. root Certificate Authority). It is the duty of the operator of each DIME, or the party on whose behalf the DIME is being operated, to validate the registration data. 5.3. Cross Cutting DIMEs use and provide various methods to protect data as described below under seven categories: Attestation, Authentication, Authorization, Access Control, Attribution, Accounting and Audit. DRIP refers to these categories collectively as AAA. The definitions of the seven categories are provided in Section 2.1. All data, handled under DRIP, MUST be protected by AAA. All private data MUST also be protected by strong encryption where permitted by law. These requirements apply to data at rest and in transit in all phases of the process, i.e. registration and query. Attestation: MAY be mandated by CAAs for devices (such as UA). Remote ATtestation ProcedureS (RATS) [RFC9334] is RECOMMENDED by DRIP. The specific attestation mechanisms in a given jurisdiction are out of scope for this document. Wiethuechter Expires 8 May 2025 [Page 8] Internet-Draft det-moc November 2024 Authentication: SHOULD be provided by DIMEs for entities participating in Broadcast RID and if provided MUST follow [RFC9575] Authorization: TODO Access Control: MUST be enforced by the DIME to access data from Section 5.1.2. The eXtensible Access Control Markup Language (XACML) MUST be used. The policies to be enforced by XACML MUST be provided by the CAA and are out of scope for this document. Attribution: TODO Accounting: TODO Audit: TODO 6. Compliance Testing Author: This section is a work in progress. All interfaces MUST be tested on valid and invalid data (such as being malformed). When policy is required on an interface all defined permutations of the policy MUST be tested. The policy engine MUST be evoked to validate proper decisions and actions are being made. All data returned from an interface MUST be tested to check that it conforms with specifications. The DRIP WG is allocated eight RAA values for experimentation and testing purposes. These can be delegated to parties, for a limited period of time at the behest of the DRIP WG, to test DIME interoperability (e.g. HDA to RAA interactions) in any of the below subsections. The IANA Considerations section of [DET-DNS] contains more information on how these delegations are to be handled. Appendix B provides a set of forms to be filled out and submitted as part of a CAA compliance process for using DRIP. +-----+ +-----+ | | | | | o----(1)--->o | | A | | B | | o<---(2)----o | | | | | +-----+ +-----+ Figure 1: System Interface Test Diagram Wiethuechter Expires 8 May 2025 [Page 9] Internet-Draft det-moc November 2024 6.1. Registration Interface A, B pairs: (registrant, HDA), (HDA, RAA) 1: Ensure that CoAP endpoints on B can be accessed according to B's policy by A. Ensure that the endpoints conform to the normative requirements of [DET-REGISTRATION] Test that B interface properly handles valid and malformed data. Test that B securely generates proper artifacts and stores them. 2: Ensure that the CoAP interactions for (1) properly returns data to A from B. This data MUST include the Broadcast Endorsements, X.509s and any other data elements required. 6.2. Public Query Interface A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA') 1: Ensure that B has a properly configured and publicly accessible Authoritative Name Server for its delegated ip6.arpa domain. 2: Ensure that B returns the valid RRTypes defined in [DET-DNS] to A based on an ip6.arpa query via standard DNS methods (i.e. using UDP on port 53). Ensure that the HHIT RRType contains the correct Certificate with an URI. 6.3. Private Query Interface A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA') 1: Ensure that the provide URI from the public query interface points to a valid URI. Ensure that the endpoint on B has proper AAA mechanisms as defined in this document and enforces the proper policy options. 2: Ensure that the B endpoint securely returns the data expected according to policy (matrix of authorized, valid request, unauthorized and invalid request) to A. Wiethuechter Expires 8 May 2025 [Page 10] Internet-Draft det-moc November 2024 7. IANA Considerations This document requires no new or modified actions by IANA. It does depend on actions IANA has already undertaken to perform in support of DRIP [DET-DNS]. It also informs other parties of interactions they must have with IANA to achieve the intended purposes of this document; e.g. Nation states MUST request IANA delegation of the DNS zone under ip6.arpa corresponding to their allocated RAA values. 8. Security Considerations The considerations discussed in [RFC9153], [RFC9434], [RFC9374], [RFC9575] and [DET-DNS] apply. 8.1. DETs as a Locator TODO 9. Privacy & Transparency Considerations The considerations discussed in [RFC9153] apply. 9.1. DETs as Session ID and Authentication Key ID The properties of a DET allow it to be used as a Session ID and/or an Authentication Key ID. There may be scenarios in which Session IDs are desired for privacy but Authentication is not; although this may reduce transparency and security, a DET MAY be used exclusively as a Session ID in such. There are scenarios in which Authentication is desired but Session IDs are not (e.g. where a CAA does not allow Session IDs); a DET MAY be used exclusively as an Authentication Key ID in such. In the scenario expected to be most common, both Session IDs and Authentication are desired; the same DET SHOULD be used as both the Session ID and Authentication Key ID in such. 9.2. Selective Encryption The DET, in its capacity as a Session ID, already acts as a query key for various data elements (both public and private). Selective encryption MAY be allowed when using a Session ID to allow authorized parties to obtain decryption as a service (under UTM, from the USS under which the observed UA is flying) or access decryption key material (under UTM or not, from the HDA) via a private lookup. This enables the encryption of selected data elements in Broadcast RID to provide a layer of privacy for operators (e.g. their position) without compromising transparency to entities (e.g.public safety / law enforcement personnel) that need to know. Wiethuechter Expires 8 May 2025 [Page 11] Internet-Draft det-moc November 2024 Selective encryption typically requires network connectivity of the Observer to perform the private query to obtain the decryption service or key material. CAAs should consider the expected Observer environment and prohibit encryption wherever and whenever Observers cannot reasonably be expected to have connectivity. For example selective encryption, per CAA regulations, MAY be allowed in dense urban areas but prohibited in rural areas. The issue of Observer network connectivity MAY be mitigated with the use of a shared key, for encryption/decryption, used by multiple Session IDs in a given HDA over a period of time, that is preloaded onto the Observer before connectivity is lost. For example Observers MAY query HDAs for flight volumes in which they are interested to preload their decryption key(s) for the registrations that day. 10. References 10.1. Normative References [DET-DIFF-ACCESS] Wiethuechter, A., "DRIP Entity Tag (DET) Differentiated Access using RDAP", Work in Progress, Internet-Draft, draft-wiethuechter-drip-det-diff-access-rdap-00, 27 September 2024, . [DET-DNS] Wiethuechter, A. and J. Reid, "DRIP Entity Tags (DET) in the Domain Name System (DNS)", Work in Progress, Internet- Draft, draft-ietf-drip-registries-19, 4 November 2024, . [DET-REGISTRATION] Wiethuechter, A., "DRIP Entity Tag (DET) Registration using CoAP & CWTs", Work in Progress, Internet-Draft, draft-wiethuechter-drip-det-registration-coap-cwt-00, 27 September 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Wiethuechter Expires 8 May 2025 [Page 12] Internet-Draft det-moc November 2024 [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022, . [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, . [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July 2023, . [RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)", RFC 9575, DOI 10.17487/RFC9575, June 2024, . 10.2. Informative References [F3411] ASTM International, "Standard Specification for Remote ID and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July 2022, . [F3586] ASTM International, "Standard Practice for Remote ID Means of Compliance to Federal Aviation Administration Regulation 14 CFR Part 89", ASTM F3586-22, DOI 10.1520/F3586-22, July 2022, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Wiethuechter Expires 8 May 2025 [Page 13] Internet-Draft det-moc November 2024 [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Appendix A. HID Abbreviation The DET MAY be abbreviated. This is useful for display application with limited screen real-estate as the display of the entire 128-bit (32-character in hexadecimal) IPv6 address can be costly. Abbreviations SHOULD follow the following format rules. Hierarchy Level: Each hierarchy level (RAA/HDA) is represented by a maximum of four alphanumeric characters. This abbreviation SHOULD NOT be a single character in length, for obvious reasons of not being very useful. The decimal representation does fit into the 4 character restriction but is NOT RECOMMENDED. The RECOMMENDED abbreviation for the RAA level is to use the ISO3166-1 Alpha 2 code for nations. This abbreviation MAY be found in DNS under a HHIT RRType of the entity or its parents. If there is no abbreviation hint display devices SHOULD use a fixed size four character hexadecimal representation of the value. It is RECOMMENDED that display applications specify a default RAA value, and only display the RAA abbreviation explicitly when it does not match the default. Entity Hash: The entity is represented by a fixed size four character hexadecimal string using the last four characters of the DET. If a collision (within the same HID space) on display occurs, the four characters SHOULD shift to the left by one hexadecimal character until the collision is resolved. This window MUST stay within the last sixteen hexadecimal characters of the DET. The : character found in an IPv6 address string is ignored. Delimiter: Each section is delimited by a single character. This can be any whitespace character (except newline and tab) or any non-alphanumeric character (period, comma, semicolon, etc.). It is RECOMMENDED that the delimiter is consistent between components. The RECOMMENDED delimiter is the space character. For example a DET with the values of RAA 16383 and HDA 1 without any abbreviation hint from DNS is represented by the string 3FFF 0001 xxxx with xxxx representing a entity hash. If an abbreviation for the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then the DET can be represented with the string of DRIP01 TEST xxxx. Wiethuechter Expires 8 May 2025 [Page 14] Internet-Draft det-moc November 2024 For an example of the entity hash, let's assume there are two DETs with the following hashes in the same HID: 0000:1111:2222:3333 and 0000:2222:1111:3333. At first both DETs are represented with the same abbreviation: RAA HDA 3333. One of these DETs is selected by the display application to shift the display hash one character to avoid the collision resulting in the following two abbreviations: RAA HDA 3333 and RAA HDA 1333. Appendix B. Compliance Submission Forms TODO Author's Address Adam Wiethuechter AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Wiethuechter Expires 8 May 2025 [Page 15]