DRIP Entity Tags (DET) in the Domain Name System (DNS)
Internet-Draft draft-ietf-drip-registries-20
Adam Wiethuechter, Ed.
AX Enterprize, LLC
4947 Commercial Drive
Yorkville
NY
13495
USA
adam.wiethuechter@axenterprize.com
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
UK
jim@rfc1035.com
15 November 2024
Internet
drip Working Group
Internet-Draft
This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata.
Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information from RID is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 4 of [RFC9434]).
When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID, extended information can be retrieved from a DRIP Identity Management Entity (DIME) which manages registration of and associated lookups from DETs. In this document we assume the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be independent or handled by another entity as well.
General Concept
DRIP Entity Tags (DETs) embedded a hierarchy scheme which is mapped onto the Domain Name System (DNS). DIME's enforce registration and information access of data associated with a DET while also providing the trust inherited from being a member of the hierarchy. Other identifiers and their methods are out of scope for this document.
Authoritative Name Servers of the Domain Name System (DNS) provide the Public Information such as the cryptographic keys, endorsements and certificates of DETs and pointers to Private Information resources. Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication defined [RFC9575] for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy.
Aspects of Private Information Registries to store and protect, through AAA mechanisms, Personally Identifiable Information (PII) are not described in this document.
Use of Existing DNS Models
DRIP relies on the DNS and as such roughly follows the registrant-registrar-registry model. In DRIP, the registrant would be the end user who owns/controls the Unmanned Aircraft. They are ultimately responsible for the DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Registrars typically provide optional additional services such as DNS hosting.
The registry maintains a database of the registered domain names and their related metadata such as the contact details for domain name holder and the relevant registrar. The registry provides DNS service for the zone apex which contains delegation information for domain names. Registries generally provide services such as WHOIS or RDAP to publish metadata about the registered domain names and their registrants and registrars.
Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: the registrant buys services from a registrar who pays for services provided by the registry.
By definition, there can only be one registry for a domain name. Since that registry is a de facto monopoly, the scope of its activities are usually kept to a minimum to reduce the potential for market distortions or anti-competitive practices. A registry can have an arbitrary number of registrars who compete with each other on price, service and customer support.
It is not necessary, and in some case may not be desirable, for DRIP registrations to strictly follow this registrant-registrar-registry model. Prevailing circumstances and/or local policy may mean some combination of these roles could be combined. A DRIP registry might be operated by the CAA. Or it could be outsourced to a DNS registry provider. Registration policies - pricing, renewals, registrar and registrant agreements, etc. - will need to be developed. These considerations SHOULD be determined by the CAA, perhaps in consultation with local stakeholders. They are are out of scope for this document.
The specifics for the UAS RID use case are detailed in the rest of document.
Scope
The scope of this document is limited to the 2001:30::/28 IPv6 prefix and its associated reverse domain in DNS for DETs being used in UAS RID for participating parties (UA, Observer devices, DIMEs, etc.).
Other sectors may adopt this technology. It is RECOMMENDED that a global Apex (i.e. IPv6 prefix) and international Apex manager be designated for each sector.
Terminology
Required 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.
Additional Definitions
This document makes use of the terms (PII, USS, etc.) defined in [RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434], while others (RAA, HDA, etc.) are from [RFC9374].
DET Hierarchy in DNS
[RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and further specifies an instance of them used for UAS RID called DETs. The HHIT is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator. It's format is in Figure 1 and further information is in [RFC9374].
DRIP Entity Tag Breakdown

+-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28-bits)   | (28-bits)    | (8-bits)      | (64-bits)   |
+-------------+--------------+---------------+-------------+
             /                \
            /                  \
           /                    \-----------------------------\
          /                                                    \
         /                                                      \
        +--------------------------------+-----------------------+
        | Registered Assigning Authority | HHIT Domain Authority |
        | (14-bits)                      | (14-bits)             |
        +--------------------------------+-----------------------+

The IPv6 Prefix, assigned by IANA for DETs is 2001:30::/28. The corresponding domain (nibble reversed as 3.0.0.1.0.0.2.ip6.arpa) is owned by the IAB.
Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address, the upper level of hierarchy (i.e. RAAs) "borrows" the upper two bits of their respective HDA space for DNS delegation. As such the IPv6 prefix of RAAs are 2001:3x:xxx::/44 and HDAs are 2001:3x:xxxx:xx::/56 with respective nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa and y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.
Preallocations have been made based on the ISO 3166-1 Numeric Nation Code [ISO3166-1]. This is to support the initial use case of DETs in UAS RID on an international level. See Section 6.2.1 for the RAA allocations.
The HDA values of 0, 4096, 8192 and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits), specifically when to register with the Apex and endorse delegations of HDAs in their namespace.
The administration, management and policy for operation a DIME at any level in the hierarchy (Apex, RAA or HDA), be it external or from a parent level, is out of scope for this document. In some cases, such as the RAAs and HDAs of a nation, these are National Matters which are to be dealt with by those parties accordingly.
Public Information Registry
Per [RFC9434] all information classified, by all parties involved, as public is stored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from [RFC9153].
Authoritative Name Servers use domain names as handles and data is stored in Resource Records (RR) with associated RRTypes. This document defines two new RRTypes, one for HHIT metadata (HHIT, Section 5.1) and another for UAS Broadcast RID information (BRID, Section 5.2). The former RRType is particularly important as it contains a URI (as part of the certificate) that point to Private Information resources.
DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed per convention) with at minimum an HHIT RRType. Depending on local circumstances or additional use cases other RRTypes MAY be present. For UAS RID the BRID RRType MUST be present to provide the Broadcast Endorsements defined in [RFC9575].
DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies.
UAS specific information, such as physical characteristics, MAY also be stored in DNS but is out of scope for this document. This specification information is currently drafted in [uas-sn-dns].
Lookups of the above RRTypes are performed with the standard DNS methodology using the nibble reversed DET as the query name affixed to the ip6.arpa domain apex and asking for the specific RRType. The HHIT RRType provides the public key for signature verification and URIs via the certificate. The BRID RRType provides static Broadcast RID information such as the Broadcast Endorsements sent following [RFC9575].
Resource Records
HHIT Resource Record
The HHIT Resource Record is a metadata record for various bits of HHIT specific information that isn't available in the pre-existing HIP RRType.
HHIT Wire Format

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        HHIT Data Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                   HHIT Data (CBOR Encoded)                    .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The HHIT Data Length is 32-bit integer representing the number of bytes contained in the HHIT Data field. The HHIT Data field MUST be encoded in CBOR bytes. The CDDL of the HHIT Data is provided in Figure 3.
Text Representation
The HHIT Data is represented in base64 and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the HHIT Data portion has internal subfields, but these do not appear in the master file representation only a single logical base64 string will appear. The HHIT Data Length is not represented as it is implicitly known by the HHIT Data.
Presentation Representation
The HHIT Data portion MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610].
Field Descriptions
HHIT Wire Format CDDL

hhit-rr = [
    type: uint .size(2),
    abbreviation: tstr .size(15),
    registration-cert: bstr / #6.TBD
]

HHIT Entity Type:
This field is two octets with values defined in Section 6.2.2. It is envisioned that there may be many types of HHITs in use. In some cases it may be helpful to understand the HHITs role in the ecosystem like described in [drip-dki]. This field provides such context.
HID Abbreviation:
This field is meant to provide an abbreviation to the HID structure for display devices. The specific contents of this field are not defined here.
Canonical Registration Certificate:
This field is reserved for any certificate to endorse registration that contains the DET. It is in either encoded as X.509 DER or C.509.
UAS Broadcast RID Resource Record
The UAS Broadcast RID Resource Record type (BRID) is a format to hold public information typically sent of the UAS Broadcast RID that is static. It can act as a data source if information is not received over Broadcast RID or for cross validation.
BRID Wire Format

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        BRID Data Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                   BRID Data (CBOR Encoded)                    .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The BRID Data Length is 32-bit integer representing the number of bytes contained in the BRID Data field. The BRID Data field MUST be encoded in CBOR bytes. The CDDL of the BRID Data is provided in Figure 5.
Text Representation
The BRID Data is represented in base64 and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the BRID Data portion has internal subfields, but these do not appear in the master file representation only a single logical base64 string will appear. The BRID Data Length is not represented as it is implicitly known by the BRID Data.
Presentation Representation
The BRID Data portion MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610]. All byte strings longer than a length of 20 SHOULD be displayed as base64 when possible.
Field Descriptions
BRID Wire Format CDDL

bcast-rr = {
    uas_type: nibble-field,
    uas_ids: [+ uas-id-grp],
    ? auth: [+ auth-grp],
    ? self-grp,
    ? op_type: 0..3,
    ? area-grp,
    ? classification-grp,
    ? operator-grp
}
uas-id-grp = (
    id_type: &uas-id-types,
    uas_id: bstr .size(20)
)
uas-id-types = (none: 0, serial: 1, caa_id: 2, utm_id: 3, session_id: 4)
auth-grp = (
    a_type: nibble-field,
    a_data: bstr .size(1..362)
)
area-grp = (
    area_count: 1..255,
    area_radius: float,
    area_floor: float,
    area_ceiling: float
)
classification-grp = (
    ua_class: 0..8,
    eu_class: nibble-field,
    eu_category: nibble-field
)
self-grp = (
    desc_type: nibble-field,
    description: tstr .size(23)
)
operator-grp = (
    operator_id_type: nibble-field,
    operator_id: bstr .size(20)
)
nibble-field = 0..15

The field names and their general typing are borrowed from the ASTM [F3411] data dictionary. See that document for additional information on fields semantics and units.
IANA Considerations
DRIP Prefix Delegation
This document requests that the IANA delegate the 3.0.0.1.0.0.2.ip6.arpa domain. IANA will be responsible for processing requests under the guidance of the Designated Expert.
IANA DRIP Registry
DRIP RAA Allocations
This document requests a new registry for RAA Allocations under the DRIP registry group to be managed by IANA.
RAA Allocations:
a 14-bit value used to represent RAAs. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values/ranges are defined:
RAA Value(s) | Status | Allocation | Reference
0 - 3 | Reserved | N/A | N/A
4 - 3999 | Allocated | ISO 3166-1 Countries | This RFC
4000 - 16375 | Reserved | N/A | N/A
16376 - 16383 | Allocated | DRIP WG (Experimental Use) | This RFC
To support DNS delegation in ip6.arpa a single RAA is given 4 delegations by borrowing the upper two bits of HDA space. This enables a clean nibble boundary in DNS to delegate from (i.e. the prefix 2001:3x:xxx0::/44). These HDAs (0, 4096, 8192 and 12288) are reserved for the RAA.
The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found as a CSV file on GitHub. Each Nation is assigned four RAAs that are left to the national authority for their purpose. For RAAs under this range a shorter prefix of 2001:3x:xx00::/40 MAY be delegated to each CAA, which covers all 4 RAAs (and reserved HDAs) assigned to them.
Requests in the DRIP WG allocation block MUST be forwarded to the contact point in the DRIP WG to evaluate the request and MUST contain a desired/proposed length of time for the allocation. Allocations in the block are not permanent and have a limited time the delegation is to be supported. The length of the time proposed is evaluated on a case-by-case basis by the DRIP WG and can result in negotiations for adjustment.
HHIT Entity Type
This document requests a new registry for HHIT Entity Type under the DRIP registry group.
HHIT Entity Type:
numeric, 16-bit, field of the HHIT RRType to encode the HHIT Entity Type. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values are defined:
Value | Type | Reference
0 | Not Defined | This RFC
1 | DRIP Identity Management Entity (DIME) | This RFC
2 | DIME: Authentication CA | [drip-dki]
3 | DIME: Issuing CA | [drip-dki]
4 | Reserved | This RFC
5 | Apex | This RFC
6 | Apex: Authentication CA | [drip-dki]
7 | Apex: Issuing CA | [drip-dki]
8 | Reserved | This RFC
9 | Registered Assigning Authority (RAA) | This RFC
10 | RAA: Authentication CA | [drip-dki]
11 | RAA: Issuing CA | [drip-dki]
12 | Reserved | This RFC
13 | HHIT Domain Authority (HDA) | This RFC
14 | HDA: Authentication CA | [drip-dki]
15 | HDA: Issuing CA | [drip-dki]
16 | Uncrewed Aircraft (UA) | This RFC
17 | Ground Control Station (GCS) | This RFC
18 | Uncrewed Aircraft System (UAS) | This RFC
19 | Remote Identification (RID) Module | This RFC
20 | Pilot | This RFC
21 | Operator | This RFC
22 | Discovery & Synchronization Service (DSS) | This RFC
23 | UAS Service Supplier (USS) | This RFC
24 | Network RID Service Provider (SP) | This RFC
25 | Network RID Display Provider (DP) | This RFC
26 | Supplemental Data Service Provider (SDSP) | This RFC
27 - 65535 | Reserved | N/A
Future additions to this registry MUST NOT be allowed if they can be covered under an existing registration.
Security Considerations
DNS Operational Considerations
The Registrar and Registry are commonly used concepts in the DNS. These components interface the DIME into the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate. The following RFC provide suitable guidance: [RFC7720], [RFC4033], [RFC4034], [RFC4035], [RFC5155], [RFC8945], [RFC2182], [RFC4786], [RFC3007].
If DNSSEC is used, a DNSSEC Practice Statement (DPS) SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. [RFC6841] documents a Framework for DNSSEC Policies and DNSSEC Practice Statements.
The interfaces and protocol specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected registry-registrar activity will use the Extensible Provisioning Protocol (EPP) [RFC5730]. The registry SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP [RFC9082] to provide public information about registered domain names.
Decisions about DNS or registry best practices and other operational matters SHOULD be made by the CAA, ideally in consultation with local stakeholders. This document RECOMMENDS that DNSSEC SHOULD be used by both Apex (to control RAA levels) and RAA (to control HDA level) zones.
Public Key Exposure
DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. [RFC9374] security considerations cover various attacks on such keys.
While unlikely the forging of a corresponding private key is possible if given enough time (and computational power). As such it is RECOMMENDED that the public key for any DET not be exposed in DNS (under any RRType) until it is required.
Optimally this requires the UAS somehow signal the DIME that a flight using a Specific Session ID will soon be underway or complete. It may also be facilitated under UTM if the USS (which may or may not be a DIME) signals when a given operation using a Session ID goes active.
Contributors
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundations for the content and processes of this architecture and document.
References
Normative References
[RFC9153]

Drone Remote Identification Protocol (DRIP) Requirements and Terminology
S. Card, Ed.
A. Wiethuechter
R. Moskowitz
A. Gurtov
February 2022
RFC 9153
DOI 10.17487/RFC9153
[RFC9374]

DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
R. Moskowitz
S. Card
A. Wiethuechter
A. Gurtov
March 2023
RFC 9374
DOI 10.17487/RFC9374
[RFC9434]

Drone Remote Identification Protocol (DRIP) Architecture
S. Card
A. Wiethuechter
R. Moskowitz
S. Zhao, Ed.
A. Gurtov
July 2023
RFC 9434
DOI 10.17487/RFC9434
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[drip-dki]

The DRIP DET public Key Infrastructure
Robert Moskowitz
HTT Consulting
Stuart W. Card
AX Enterprize, LLC
23 October 2023
Internet-Draft draft-moskowitz-drip-dki-09
[uas-sn-dns]

UAS Serial Numbers in DNS
Adam Wiethuechter
AX Enterprize, LLC
25 June 2024
Internet-Draft draft-wiethuechter-drip-uas-sn-dns-02
[RFC5730]

Extensible Provisioning Protocol (EPP)
S. Hollenbeck
August 2009
STD 69
RFC 5730
DOI 10.17487/RFC5730
[RFC6841]

A Framework for DNSSEC Policies and DNSSEC Practice Statements
F. Ljunggren
AM. Eklund Lowinder
T. Okubo
January 2013
RFC 6841
DOI 10.17487/RFC6841
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC9082]

Registration Data Access Protocol (RDAP) Query Format
S. Hollenbeck
A. Newton
June 2021
STD 95
RFC 9082
DOI 10.17487/RFC9082
[RFC9575]

DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)
A. Wiethuechter, Ed.
S. Card
R. Moskowitz
June 2024
RFC 9575
DOI 10.17487/RFC9575
[RFC4033]

DNS Security Introduction and Requirements
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4033
DOI 10.17487/RFC4033
[RFC5155]

DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
B. Laurie
G. Sisson
R. Arends
D. Blacka
March 2008
RFC 5155
DOI 10.17487/RFC5155
[RFC8945]

Secret Key Transaction Authentication for DNS (TSIG)
F. Dupont
S. Morris
P. Vixie
D. Eastlake 3rd
O. Gudmundsson
B. Wellington
November 2020
STD 93
RFC 8945
DOI 10.17487/RFC8945
[RFC4034]

Resource Records for the DNS Security Extensions
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4034
DOI 10.17487/RFC4034
[RFC4035]

Protocol Modifications for the DNS Security Extensions
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4035
DOI 10.17487/RFC4035
[RFC3007]

Secure Domain Name System (DNS) Dynamic Update
B. Wellington
November 2000
RFC 3007
DOI 10.17487/RFC3007
[RFC2182]

Selection and Operation of Secondary DNS Servers
R. Elz
R. Bush
S. Bradner
M. Patton
July 1997
BCP 16
RFC 2182
DOI 10.17487/RFC2182
[RFC7720]

DNS Root Name Service Protocol and Deployment Requirements
M. Blanchet
L-J. Liman
December 2015
BCP 40
RFC 7720
DOI 10.17487/RFC7720
[RFC3912]

WHOIS Protocol Specification
L. Daigle
September 2004
RFC 3912
DOI 10.17487/RFC3912
[RFC4786]

Operation of Anycast Services
J. Abley
K. Lindqvist
December 2006
BCP 126
RFC 4786
DOI 10.17487/RFC4786
[F3411]

Standard Specification for Remote ID and Tracking
ASTM International
July 2022
ASTM F3411-22A
DOI 10.1520/F3411-22A
[ISO3166-1]

Codes for the representation of names of countries and their subdivisions
International Standards Organization (ISO)
August 2020
ISO 3166-1:2020