<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.24 (Ruby 3.2.3) --> <?rfc comments="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-drip-registries-33" number="9886" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.27.0 -->version="3" xml:lang="en" updates="" obsoletes="" submissionType="IETF"> <front> <title abbrev="DET in DNS">DRIP Entity Tags (DETs) in the Domain Name System</title> <seriesInfoname="Internet-Draft" value="draft-ietf-drip-registries-33"/>name="RFC" value="9886"/> <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" role="editor"> <organization>AX Enterprize, LLC</organization> <address> <postal> <street>4947 Commercial Drive</street> <city>Yorkville</city> <region>NY</region> <code>13495</code><country>USA</country><country>United States of America</country> </postal> <email>adam.wiethuechter@axenterprize.com</email> </address> </author> <author initials="J." surname="Reid" fullname="Jim Reid"> <organization>RTFM llp</organization> <address> <postal> <street>St Andrews House</street> <city>382 Hillington Road, Glasgow Scotland</city> <code>G51 4BL</code><country>UK</country><country>United Kingdom</country> </postal> <email>jim@rfc1035.com</email> </address> </author> <date year="2025"month="August" day="19"/> <area>Internet</area> <workgroup>drip Working Group</workgroup> <keyword>Internet-Draft</keyword>month="December"/> <area>INT</area> <workgroup>drip</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 81?><t>This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS RemoteIDIdentification and other services.</t> </abstract> </front> <middle><?line 85?><section anchor="introduction"> <name>Introduction</name> <t>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 <xreftarget="rfc9434-fig4"/>;target="rfc9434-fig4"/>, which is the same as Figure 4 of <xref target="RFC9434"/>).</t> <figure anchor="rfc9434-fig4"> <name>Global UAS RID Usage Scenario (Figure 4 ofRFC9434)</name>RFC 9434)</name> <artwork align="center"><![CDATA[ *************** *************** * UAS1 * * UAS2 * * * * * * +--------+ * DAA/V2V * +--------+ * * | UA o--*----------------------------------------*--o UA | * * +--o--o--+ * * +--o--o--+ * * | | * +------+ Lookups +------+ * | | * * | | * | GPOD o------. .------o PSOD | * | | * * | | * +------+ | | +------+ * | | * * | | * | | * | | * * C2 | | * V2I ************ V2I * | | C2 * * | '-----*--------------* *--------------*-----' | * * | * * * * | * * | o====Net-RID===* *====Net-RID===o | * * +--o--+ * * Internet * * +--o--+ * * | GCS o-----*--------------* *--------------*-----o GCS | * * +-----+ * Registration * * Registration * +-----+ * * * (and UTM) * * (and UTM) * * *************** ************ *************** | | | +----------+ | | | +----------+ | Public o---' | '---o Private | | Registry | | | Registry | +----------+ | +----------+ +--o--+ | DNS | +-----+ DAA: Detect And Avoid GPOD: General Public Observer Device PSOD: Public Safety Observer Device V2I: Vehicle-to-Infrastructure V2V:Vehicle-to-Vehicle ]]></artwork>Vehicle-to-Vehicle]]></artwork> </figure> <t>When a DRIP Entity Tag (DET) <xref target="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 it is assumed the DIME is a function of UAS Service Suppliers (USS)(Appendix A.2 of <xref target="RFC9434"/>)(<xref section="A.2" target="RFC9434"/>), but a DIME can be independent or handled by another entity as well.</t> <section anchor="general-concept"> <name>General Concept</name> <t>DRIP Entity Tags (DETs) embed a hierarchy schemewhichthat is mapped onto the Domain Name System (DNS) <xref target="STD13"/>. DIMEs 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.</t> <!-- [rfced] Why is "Authentication" capitalized? Does it perhaps refer to Authentication Messages or an authentication approach? Original: Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication defined in [RFC9575] for Broadcast RID. --> <t>Authoritative Name Servers of the DNS provide the public information such as the cryptographic keys, endorsements and certificates ofDETsDETs, and pointers to private information resources. Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication defined in <xref target="RFC9575"/> for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy.</t> <t>This document does not specify AAA mechanisms used by Private Information Registries to store and protect Personally Identifiable Information (PII).</t> </section> <section anchor="scope"> <name>Scope</name><t>The<!-- [rfced] We are having trouble parsing this sentence. Is the scope a) DNS registration of DETs with the DNS delegation of the reverse domain of the IPv6 prefix and b) RRsets used to handle DETs? Also, is "of IPv6 Prefix" correct - perhaps it should be "of the IPv6 prefix" or "of IPv6 prefixes"? Please review. Original: The scope of this document is the DNS registration of DETs with the DNS delegation of the reverse domain of IPv6 Prefix, assigned by IANA for DETs 2001:30::/28 and RRsets used to handle DETs. Perhaps: The scope of this document is the DNS registration of DETs with the DNS delegation of the reverse domain of the IPv6 Prefix (2001:30::/28 for DETs) and RRsets used to handle DETs. --> <t>The scope of this document is the DNS registration of DETs with the DNS delegation of the reverse domain of the IPv6 prefix, assigned by IANA for DETs <tt>2001:30::/28</tt> and RRsets used to handle DETs.</t> </section> </section> <section anchor="terminology"> <name>Terminology</name> <section anchor="required-terminology"> <name>Required Terminology</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="additional-definitions"> <name>Additional Definitions</name> <t>This document makes use of the terms and abbreviations from previous DRIP documents. Below are subsets, grouped by original document, of terms used this document. Please see those documents for additional context,definitionsdefinitions, and any further referenced material.</t> <t>From <xref section="2.2" sectionFormat="of"target="RFC9153"/>target="RFC9153"/>, this document uses: AAA, CAA, GCS, ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM.</t> <t>From <xref section="2" sectionFormat="of"target="RFC9434"/>target="RFC9434"/>, this document uses: Certificate, DIME, and Endorsement.</t> <t>From <xref section="2" sectionFormat="of"target="RFC9374"/>target="RFC9374"/>, this document uses: HDA, HID, and RAA.</t> </section> </section> <section anchor="det-hierarchy-in-dns"> <name>DET Hierarchy in DNS</name> <!-- [rfced] "HHIT/DET" is a bit confusing, and it is not used elsehwere in this document or any RFCs. Because DETs are a specific instance of HHIT, may we refer to just DET? Note that we deleted "as" from "is as an IPv6 address" in the suggested text. Please review and let us know how this text may be clarified. Original (prior sentence included for context): [RFC9374] defines the HHIT and further specifies an instance of them used for UAS RID called DETs. The HHIT/DET is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator. Perhaps (note that we made "DETs" singular here): [RFC9374] defines the HHIT and further specifies an instance of them used for UAS RID called DET. The DET is a 128-bit value that is an IPv6 address intended primarily as an identifier rather than locator. --> <t><xref target="RFC9374"/> defines theHHITHierarchical Host Identity Tags (HHIT) and further specifies an instance of them used for UAS RID called DETs. The HHIT/DET is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator.ItsThe format is shown in <xreftarget="hhit-fig"/>, shown here for reference,target="hhit-fig"/> and further information is in <xref target="RFC9374"/>.</t> <figure anchor="hhit-fig"> <name>DRIP Entity Tag Breakdown</name> <artwork align="center"><![CDATA[ +-------------+--------------+---------------+-------------+ | 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) |+--------------------------------+-----------------------+ ]]></artwork>+--------------------------------+-----------------------+]]></artwork> </figure> <t><xref target="RFC9374"/> assigns the IPv6 prefix <tt>2001:30::/28</tt> for DETs. Its corresponding domain name for reverse lookups is <tt>3.0.0.1.0.0.2.ip6.arpa.</tt>. The IAB has administrative control of this domain name.</t> <t>Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address (Section2.5<xref section="2.5" sectionFormat="bare" target="RFC3596"/> of RFC 3596 <xref target="STD88"/>), the upper level of the hierarchy (i.e., Registered Assigning Authority (RAA)) "borrows" the upper two bits of their respective HHIT Domain Authority (HDA) space for DNS delegation. Assuchsuch, the IPv6 prefix of RAAsareis <tt>2001:3x:xxx0::/44</tt> and HDAsareis <tt>2001:3x:xxxy:yy00::/56</tt> with respective nibble reverse domains of <tt>x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.</tt> and <tt>y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.</tt>.</t> <t>This document preallocates a subset of RAAs based on the ISO 3166-1 Numeric Nation Code <xref target="ISO3166-1"/>. This is to support the initial use case of DETs in UAS RID on an international level. See <xref target="iana-raa"/> for the RAA allocations.</t> <t>The HDA values of 0, 4096,81928192, and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits),specificallyin particular to specify when to register with the apex and endorse delegations of HDAs in their namespace.</t> <t>The administration,managementmanagement, and policy for the operation of a DIME at any level in the hierarchy (Apex, RAA or HDA) is out of scope for this document. For RAAs or DETs allocated on a per-country basis, these considerations should bebedetermined by the appropriate national authorities, presumably the Civil Aviation Authority (CAA).</t> <section anchor="use-of-existing-dns-models"> <name>Use of Existing DNS Models</name> <t>DRIP relies on the DNS and as such roughly follows the registrant-registrar-registry model. In the UAS ecosystem, 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.</t> <t>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 zoneapexapex, which contains delegation information for domain names. Registries generally provide services suchRDAPas the Registration Data Access Protocol (RDAP) <xref target="STD95"/> or equivalent to publish metadata about the registered domain names and their registrants and registrars.</t> <t>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.</t> <t>By definition, there can only be one registry for a domain name. A registry can have an arbitrary number of registrars who compete with each other on price,serviceservice, and customer support.</t> <section anchor="dns-model-considerations-for-dimes"> <name>DNS Model Considerations for DIMEs</name> <figure anchor="dns-model-fig"> <name>Example DRIP DNS Model</name> <artwork align="center"><![CDATA[ Apex Registry/Registrar (IANA) +=========================+ | 3.0.0.1.0.0.2.ip6.arpa. | +============o============+ | --------------------------------------|------------------------- National | Registries/Registrars | (RAA) | | +--------------+--------------o-+---------------+ | | | | +=====o====+ +====o=====+ +=====o====+ +=====o====+ | 0.0.0.0. | | 1.0.0.0. | | 2.0.0.0. | | 3.0.0.0. | +====o=====+ +====o=====+ +====o=====+ +====o=====+ | ---------------------------------------|------------------------ Local | Registries/Registrars | (HDA) | | +--------------+---------------o--------...-----+ | | | | +=====o====+ +====o=====+ +====o=====+ +=====o====+ | 1.0.0. | | 2.0.0. | | 3.0.0. | | f.f.f. | +====o=====+ +=====o====+ +====o=====+ +====o=====+ | ---------------------------------------|------------------------ Local | Registrants | +=====================o================+ | x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. |+======================================+ ]]></artwork>+======================================+]]></artwork> </figure> <t>While the registrant-registrar-registry model is mature and well understood, it may not be appropriate for DRIP registrations in some circumstances. It could add costs andcomplexity; developingcomplexity to develop policies and contracts as outlined above. On the other hand, registries and registrars offer customerservice/supportservice and support and can provide the supporting infrastructure for reliable DNS and RDAP service.</t> <t>Another approach could be to handle DRIP registrations in a comparable way to how IP address space gets provisioned. Here, blocks of addresses get delegated to a "trusted" third party, typically an ISP, who then issues IP addresses to its customers. For DRIP, blocks of IP addresses could be delegated from the <tt>3.0.0.1.0.0.2.ip6.arpa.</tt> domain (reverse domain of prefix allocated by <xref target="RFC9374"/>) to an entity chosen by the appropriate Civil Aviation Authority (CAA). This third party would be responsible for the corresponding DNS and RDAP infrastructure for these IP address blocks. They would also provision theHierarchical Host Identity Tag (HHIT, <xref target="RFC9374"/>)HHIT records <xref target="RFC9374"/> for these IP addresses. Inprincipleprinciple, a manufacturer or vendor of UAS devices could provide that role. This is shown as an example in <xref target="dns-model-fig"/>.</t> <t>Dynamic DRIP registration is another possible solution, for example when the operator of a UAS device registers its corresponding HHIT record and other resources before a flight and deletes them afterwards. This may be feasible in controlled environments with well-behaved actors. However, this approach may not scale since each device is likely to need credentials for updating the IT infrastructurewhichthat provisions the DNS.</t> <t>Registration policies (pricing, renewals,registrarregistrar, and registrant agreements, etc.) will need to be developed. These considerations should be determined by the CAA, perhaps in consultation with local stakeholders to assess the cost-benefits of these approaches (and others). All of these are out of scope for this document. The specifics for the UAS RID use case are detailed in the rest of document.</t> </section> </section> </section> <section anchor="dns"> <name>Public Information Registry</name> <t>Per <xreftarget="RFC9434"/>target="RFC9434"/>, all information classified as public is stored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from <xref target="RFC9153"/>.</t> <t>Authoritative Name Servers use domain names as identifiers and data is stored in Resource Records(RR)(RRs) with associated RRTypes. This document defines two new RRTypes, one for HHIT metadata (HHIT, <xref target="hhit-rr"/>) and another for UAS Broadcast RID information (BRID, <xref target="bcast-rr"/>). The former RRType is particularly important as it contains a URI (as part of the certificate) that points to Private Information resources.</t> <t>DETs, being IPv6 addresses, are to be under <tt>ip6.arpa.</tt> (nibble reversed per Section2.5<xref section="2.5" sectionFormat="bare" target="RFC3596"/> of RFC 3596 <xref target="STD88"/>) andMUST<bcp14>MUST</bcp14> resolve to an HHIT RRType. Depending on local circumstances or additional usecasescases, other RRTypesMAY<bcp14>MAY</bcp14> be present (for example the inclusion of the DS RRTypes or equivalent when using DNSSEC). For UASRIDRID, the BRID RRTypeMUST<bcp14>MUST</bcp14> be present to provide the Broadcast Endorsements (BEs) defined in <xref section="3.1.2.1" sectionFormat="of" target="RFC9575"/>.</t> <t>DNSSECMUST<bcp14>MUST</bcp14> be used for apex entities (those which use a self-signed <tt>Canonical Registration Certificate</tt>) and isRECOMMENDED<bcp14>RECOMMENDED</bcp14> for other entities. When a DIME decides to useDNSSECDNSSEC, theySHOULD<bcp14>SHOULD</bcp14> define a framework for cryptographic algorithms and key management <xref target="RFC6841"/>. This may be influenced by the frequency of updates, size of the zone, and policies.</t> <t>UAS-specific information, such as physical characteristics, may also be stored in DNS but is out of scope for this document.</t> <t>A DET IPv6 address gets mapped into domain names using the scheme defined in Section2.5<xref section="2.5" sectionFormat="bare" target="RFC3596"/> of RFC 3596 <xref target="STD88"/>.HoweverHowever, DNS lookups of these names query for HHIT and/or BRID resource records rather than the PTR resource records conventionally used in reverse lookups of IP addresses. For example, the HHIT resource record for the DET <tt>2001:30::1</tt> would be returned from a DNS lookup for the HHIT QTYPE for <tt>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.arpa.</tt>.</t> <t>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 sentfollowingas described in <xref target="RFC9575"/>.</t> </section> <section anchor="resource-records"> <name>Resource Records</name> <section anchor="hhit-rr"> <name>HHIT Resource Record</name> <!-- [rfced] Would it be beneficial to the reader to include a reference for HIP RRType? Perhaps an informative reference to RFC 8005? Original: The HHIT Resource Record (HHIT, RRType 67) is a metadata record for various bits of HHIT-specific information that isn't available in the pre-existing HIP RRType. --> <t>The HHIT Resource Record (HHIT, RRType 67) is a metadata record for various bits of HHIT-specific information that isn't available in the pre-existing HIP RRType. The HHIT RRType does not replace the HIP RRType. The primary advantage of the HHIT RRType over the existing RRType is the mandatory inclusion of the <tt>Canonical Registration Certificate</tt> containing an entity's public key signed by the registrar, or other trust anchor, to confirm registration.</t> <t>The dataMUST<bcp14>MUST</bcp14> be encoded inCBORthe Concise Binary Object Representation (CBOR) <xref target="RFC8949"/> bytes. TheCDDLConcise Data Definition Language (CDDL) <xref target="RFC8610"/> of the data is provided in <xref target="hhit-wire-cddl"/>.</t> <section anchor="hhit-rr-text"> <name>Text Representation</name> <t>The data are represented in base64 <xref target="RFC4648"/> 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 data has internal subfields but these do not appear in the master file representation; only a single logical base64 string will appear.</t> <section anchor="hhit-rr-presentation"> <name>Presentation Representation</name> <t>The dataMAY,<bcp14>MAY</bcp14>, for display purposes only, be represented using the Extended Diagnostic Notation as defined inAppendix G of<xref section="G" target="RFC8610"/>.</t> </section> </section> <section anchor="hhit-rr-fields"> <name>Field Descriptions</name> <figure anchor="hhit-wire-cddl"> <name>HHIT Wire Format CDDL</name><artwork><![CDATA[<sourcecode type="cddl"><![CDATA[ hhit-rr = [ hhit-entity-type: uint, hid-abbreviation: tstr .size(15), canonical-registration-cert: bstr] ]]></artwork>]]]></sourcecode> </figure> <t>All fields of the HHIT RRTypeMUST<bcp14>MUST</bcp14> be included to be properly formed.</t> <dl> <dt>HHIT Entity Type:</dt> <dd> <t>The <tt>HHIT Entity Type</tt> field is a number with values defined in <xref target="iana-hhit-type"/>. It is envisioned that there may be many types of HHITs in use. In some cases, it may be helpful to understand theHHITsrole of the HHITs in theecosystemecosystem, like that described in <xreftarget="drip-dki"/>.target="I-D.ietf-drip-dki"/>. This field provides such context. This fieldMAY<bcp14>MAY</bcp14> provide a signal of additional information and/or different handling of the data beyond what is defined in this document.</t> </dd> <dt>HID Abbreviation:</dt> <dd> <t>The <tt>HID Abbreviation</tt> field is a string that provides an abbreviation to the HID (Hierarchy ID) structure of a DET for display devices. The convention for such abbreviations is a matter of local policy. Absent of such a policy, this fieldMUST<bcp14>MUST</bcp14> be filled with the four character hexadecimal representations of the RAA and HDA (in that order) with a separatorcharactercharacter, such as aspace.space, in between. For example, a DET with an RAA value of 10 and HDA value of 20 would be abbreviated as: <tt>000A 0014</tt>.</t> </dd> <dt>Canonical Registration Certificate:</dt> <dd> <t>The <tt>Canonical Registration Certificate</tt> field is for acertificate endorsingcertificate-endorsing registration of the DET. ItMUST<bcp14>MUST</bcp14> be encoded as X.509 DER <xref target="RFC5280"/>. This certificateMAY<bcp14>MAY</bcp14> be self-signed when the entity is acting as a root of trust (i.e., an apex). Such self-signed behavior is defined by policy, such as in <xreftarget="drip-dki"/>,target="I-D.ietf-drip-dki"/>, and is out of scope for this document. This certificate is part of a chain of certificates that can be used to validate inclusion in theheirarchy.</t>hierarchy.</t> </dd> </dl> </section> </section> <section anchor="bcast-rr"> <name>UAS Broadcast RID Resource Record</name> <!-- [rfced] Is the public information static or is the UAS BRID static? Original: The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format to hold public information typically sent over UAS Broadcast RID that is static. --> <t>The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format to hold public information typically sent over 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. The primary function for DRIP isthe inclusionto include of one or more Broadcast Endorsements as defined in <xref target="RFC9575"/> in the <tt>auth</tt> field. These Endorsements are generated by the registrar upon successful registration and broadcast by the entity.</t> <t>The dataMUST<bcp14>MUST</bcp14> be encoded in CBOR <xref target="RFC8949"/> bytes. The CDDL <xref target="RFC8610"/> of the data is provided in <xref target="bcast-wire-cddl"/>.</t> <section anchor="bcast-rr-text"> <name>Text Representation</name> <t>The data are represented in base64 <xref target="RFC4648"/> 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 data has internal subfields but these do not appear in the master file representation; only a single logical base64 string will appear.</t> <section anchor="bcast-rr-presentation"> <name>Presentation Representation</name> <t>The dataMAY,<bcp14>MAY</bcp14>, for display purposes only, be represented using the Extended Diagnostic Notation as defined inAppendix G of<xref section="G" target="RFC8610"/>. All byte strings longer than a length of 20SHOULD<bcp14>SHOULD</bcp14> be displayed as base64 when possible.</t> </section> </section> <section anchor="bcast-rr-fields"> <name>Field Descriptions</name> <figure anchor="bcast-wire-cddl"> <name>BRID Wire Format CDDL</name><artwork><![CDATA[<sourcecode type="cddl"><![CDATA[ bcast-rr = { uas_type => nibble-field, uas_ids => [+ uas-id-grp], ? auth => [+ auth-grp], ? self_id => self-grp, ? area => area-grp, ? classification => classification-grp, ? operator_id => operator-grp } uas-id-grp = [ id_type: &uas-id-types, uas_id: bstr .size(20) ] auth-grp = [ a_type: &auth-types, a_data: bstr .size(1..362) ] area-grp = [ area_count: 1..255, area_radius: float, # in decameters area_floor: float, # wgs84-hae in meters area_ceiling: float # wgs84-hae in meters ] classification-grp = [ class_type: 0..8, class: nibble-field, category: nibble-field ] self-grp = [ desc_type: 0..255, description: tstr .size(23) ] operator-grp = [ operator_id_type: 0..255, operator_id: bstr .size(20) ] uas-id-types = (none: 0, serial: 1, session_id: 4) auth-types = (none: 0, specific_method: 5) nibble-field = 0..15 uas_type = 0 uas_ids = 1 auth = 2 self_id = 3 area = 4 classification = 5 operator_id =6 ]]></artwork>6]]></sourcecode> </figure> <t>The field names and their general typing areborrowedtaken from the ASTM<xref target="F3411"/>data dictionary(Table(Tables 1 andTable 2).2) <xref target="F3411"/>. See that document for additional context and background information on aviation application-specific interpretation of the field semantics. The explicitly enumerated values included in the CDDL above are relevant to DRIP for its operation. Other values may be valid but are outside the scope of DRIP operation. Application-specific fields, such as UASTypeType, are transported and authenticated by DRIP but are regarded as opaque user data to DRIP.</t> </section> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <section anchor="det-prefix-delegation"> <name>DET Prefix Delegation</name><t>The<!-- [rfced] You provided this response to our question about whether there is any text that should be handled cautiously: <atw> The IANA considerations for the prefix and RAA allocations. </atw> Please review the updates closely and let us know if any changes are needed. In particular, please note that the following text has been updated based on input from IANA. Please let us know any concerns. Original: The reverse domain for the DET Prefix, i.e.,<tt>3.0.0.1.0.0.2.ip6.arpa.</tt>,3.0.0.1.0.0.2.ip6.arpa., is managed by the IANA following the usual IANA rules. Current: The reverse domain for the DET Prefix, i.e., 3.0.0.1.0.0.2.ip6.arpa., is managed by the IANA. --> <t>The reverse domain for the DET Prefix, i.e., <tt>3.0.0.1.0.0.2.ip6.arpa.</tt>, is managed by IANA. IANA will liaise, as needed, with the International Civil Aviation Organization (ICAO) to verify the authenticity of delegations to CAAs (see <xref target="iso-range"/>).</t> </section> <section anchor="iana-drip-registry"> <name>IANA DRIP Registry</name> <section anchor="iana-raa"> <name>DRIP RAA Allocations</name><t>This document requests a new<t>IANA has created the registry for RAA Allocations under the <ereftarget="https://www.iana.org/assignments/drip">DRIPtarget="https://www.iana.org/assignments/drip" brackets="angle">"Drone Remote ID Protocol" registrygroup</eref> to be managed by IANA.</t>group</eref>.</t> <dl> <dt>RAA Allocations:</dt> <dd> <t>a 14-bit value used to represent RAAs. Future additions to this registry are to be made based on the followingrange/policyrange and policy table:</t> </dd> </dl> <!-- [rfced] Table 1: We see some differences between the Allocation column and what appears in the IANA registry (for example, the registry does not mention "ISO 3166-1 Countries"). We believe this is intentional, but please review and let us know if any change are needed. Note that we have removed "N/A" for the Reserved values in the Policy column to align with the IANA registry. Please let us know any concerns. See the DRIP RAA Allocations registry here: https://www.iana.org/assignments/drip/drip.xhtml#drip-raa --> <table anchor="raa-ranges"> <name>RAA Ranges</name> <thead> <tr> <th align="left">RAA Range</th> <th align="left">Allocation</th> <th align="left">Policy</th> </tr> </thead> <tbody> <tr> <td align="left">0 - 3</td> <td align="left">Reserved</td> <tdalign="left">N/A</td>align="left"></td> </tr> <tr> <td align="left">4 - 3999</td> <td align="left">ISO 3166-1 Countries</td> <td align="left">IESG Approval (<xref section="4.10" sectionFormat="of" target="RFC8126"/>), <xref target="iso-range"/></td> </tr> <tr> <td align="left">4000 - 8191</td> <td align="left">Reserved</td> <tdalign="left">N/A</td>align="left"></td> </tr> <tr> <td align="left">8192 - 15359</td> <td align="left">Unassigned</td> <td align="left">First Come First Served (<xref section="4.4" sectionFormat="of" target="RFC8126"/>)</td> </tr> <tr> <td align="left">15360 - 16383</td> <td align="left">Private Use</td> <td align="left">Private Use (<xref section="4.1" sectionFormat="of" target="RFC8126"/>), <xref target="experimental-range"/></td> </tr> </tbody> </table> <section anchor="raa-allocation-fields"> <name>RAA Allocation Fields</name> <dl> <dt>Value:</dt> <dd> <t>The RAA value delegated for this entry.</t> </dd> <dt>Name:</dt> <dd> <t>Name of the delegated RAA. For the ISO 3166-1 Countries (<xref target="iso-range"/>), this should be the name of the country.</t> </dd> <!-- [rfced] To match the column header in the IANA registry, should "Policy Reference" be "Reference" here? If this change is acceptable, note that RAA Registration Form would be updated as well. Original: Policy Reference: A publicly accessible link to the requirements for prospective HDA operators to register under this RAA. This field is OPTIONAL. Perhaps: Reference: A publicly accessible link to the requirements for prospective HDA operators to register under this RAA. This field is OPTIONAL. --> <dt>Policy Reference:</dt> <dd> <t>A publicly accessible link to the requirements for prospective HDA operators to register under this RAA. This field isOPTIONAL.</t><bcp14>OPTIONAL</bcp14>.</t> </dd> <dt>Contact:</dt> <dd> <t>Contact details of the administrator of this RAA that prospectiveHDAsHDA operators can make informational queries to.</t> </dd> </dl> </section> <section anchor="raa-registration-form"> <name>RAA Registration Form</name> <figure anchor="raa-form"> <name>RAA Delegation Request Form</name> <artwork><![CDATA[ Value: Name: Policy Reference: Contact: NS RRType Content (HDA=0): NS RRType Content (HDA=4096): NS RRType Content (HDA=8192): NS RRType Content(HDA=12288): ]]></artwork>(HDA=12288):]]></artwork> </figure> <t>The <tt>NS RRType Content (HDA=X)</tt> fields are used by IANA to perform the DNS delegations under <tt>3.0.0.1.0.0.2.ip6.arpa.</tt>. See <xref target="nibble-split"/> for technical details.</t> </section> <section anchor="nibble-split"> <name>Handling Nibble Split</name> <t>To support DNS delegation in<tt>3.0.0.1.0.0.2.ip6.arpa.</tt><tt>3.0.0.1.0.0.2.ip6.arpa.</tt>, a single RAA is given 4 delegations by borrowing the upper two bits of HDA space (see <xref target="raa-borrowing"/> for an example). This enables a clean nibble boundary in the DNS to delegate from (i.e., the prefix <tt>2001:3x:xxx0::/44</tt>). These HDAs (0, 4096, 8192 and 12288) are reserved for the RAA.</t> <figure anchor="raa-borrowing"> <name>Example Bit Borrowing of RAA=16376</name> <artwork align="center"><![CDATA[ 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | x | RAA=16376 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | 0 | 0 | 0 | E | F | F HDA=0,x=00 0 | 0 | 0 | 1 | E | F | F HDA=4096,x=01 0 | 0 | 0 | 2 | E | F | F HDA=8192,x=10 0 | 0 | 0 | 3 | E | F | FHDA=12288,x=11 ]]></artwork>HDA=12288,x=11]]></artwork> </figure> </section> <section anchor="iso-range"> <name>ISO 3166-1 Countries Range</name> <t>The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified and documented by IANA. Each Nation is assignedfour4 RAAs that are left to the national authority for their purpose. For RAAs under this range, a shorter prefix of <tt>2001:3x:xx00::/40</tt>MAY<bcp14>MAY</bcp14> be delegated to each CAA, which covers all 4 RAAs (and reserved HDAs) assigned to them.</t> <!-- [rfced] For readability, may we update the text as follows? Original: This range is set to IESG Approval (Section 4.10 of [RFC8126]) and IANA will liaise with the ICAO to verify the authenticity of delegation requests (using Figure 6) by CAAs. Perhaps: The registration policy for this range is set to IESG Approval (Section 4.10 of [RFC8126]) and IANA will liaise with the ICAO to verify the authenticity of delegation requests (using Figure 6) by CAAs. --> <t>This range is set to IESG Approval (<xref section="4.10" sectionFormat="of" target="RFC8126"/>) and IANA will liaise with the ICAO to verify the authenticity of delegation requests (using <xref target="raa-form"/>) by CAAs.</t><ul empty="true"> <li> <t>The<!-- [rfced] The text below has been removed as requested. However, please confirm that the info within the CSV file is not meant to be held in the IANA registry. <t indent="3">The CSV file found for the ISO to RAA mapping is on <eref target="https://github.com/ietf-wg-drip/draft-ietf-drip-registries/commit/a8da51bfcafcdf91878f8862c52830aa736782c9">GitHub</eref>. RFC Editor, please remove this note after IANA initializes the registry but before publication.</t></li> </ul>--> </section> <section anchor="experimental-range"> <name>Private Range</name> <t>If nibble-reversed lookup in DNS isdesireddesired, it can only be provided by private DNS servers as zone delegations from the global root will not be performed for this address range. Thus the RAAs (with its subordinate HDAs) in this range may be used in like manner and IANA will not delegate any value in this range to any party (as per Private Use, <xref section="4.1" sectionFormat="of" target="RFC8126"/>).</t> <t>One anticipated acceptable use of the private range is for experimentation and testing prior to request allocation or assignment from IANA.</t> </section> </section> <section anchor="iana-hhit-type"> <!-- [rfced] May we update the section title of 6.2.2 to be plural? Note that we would request that IANA update their registry accordingly. Original: 6.2.2. HHIT Entity Type This document requests a new registry for HHIT Entity Type under the DRIP registry group (https://www.iana.org/assignments/drip). Perhaps: 6.2.2. HHIT Entity Types IANA has created a new registry for HHIT Entity Types under the "Drone Remote ID Protocol" registry group <https://www.iana.org/assignments/drip>. --> <name>HHIT Entity Type</name> <t>This document requests a new registry for HHIT Entity Type under the <ereftarget="https://www.iana.org/assignments/drip">DRIPtarget="https://www.iana.org/assignments/drip" brackets="angle">"Drone Remote ID Protocol" registry group</eref>.</t> <dl> <dt>HHIT Entity Type:</dt> <dd><t>numeric,<t>Numeric, field of the HHIT RRType to encode the HHIT Entity Type. All entries in this registry are underathe First Come First Served policy (<xref section="4.4" sectionFormat="of"target="RFC8126"/>) policy.</t>target="RFC8126"/>).</t> </dd> </dl> <section anchor="hhit-type-registry-fields"> <name>HHIT Type Registry Fields</name> <dl> <dt>Value:</dt> <dd> <t>HHIT Type value of the entry.</t> </dd> <dt>HHIT Type:</dt> <dd> <t>Name of the entry and an optional abbreviation.</t> </dd> <dt>Reference:</dt> <dd> <t>Public document allocating the value and any additional information such as semantics. This can be a URL pointing to an Internet-Draft, IETF RFC, orweb-pageweb page among others.</t> </dd> </dl> </section> <section anchor="hhit-type-registration-form"> <name>HHIT Type Registration Form</name> <figure anchor="hhit-form"> <name>HHIT Type Registration Form</name> <artwork><![CDATA[ Value: HHIT Type:Reference: ]]></artwork>Reference:]]></artwork> </figure> </section> <section anchor="initial-values"> <name>Initial Values</name> <t>The following values are defined by this document:</t> <table anchor="hhit-initial"> <name>HHIT Entity Type Initial Values</name> <thead> <tr> <th align="left">Value</th> <th align="left">HHIT Type</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">Not Defined</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">1</td> <td align="left">DRIP Identity Management Entity (DIME)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">5</td> <td align="left">Apex</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">9</td> <td align="left">Registered Assigning Authority (RAA)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">13</td> <td align="left">HHIT Domain Authority (HDA)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">16</td> <td align="left">Unmanned Aircraft (UA)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">17</td> <td align="left">Ground Control Station (GCS)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">18</td> <td align="left">Unmanned Aircraft System (UAS)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">19</td> <td align="left">Remote Identification (RID) Module</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">20</td> <td align="left">Pilot</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">21</td> <td align="left">Operator</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">22</td> <td align="left">Discovery & Synchronization Service (DSS)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">23</td> <td align="left">UAS Service Supplier (USS)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">24</td> <td align="left">Network RID Service Provider (SP)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">25</td> <td align="left">Network RID Display Provider (DP)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">26</td> <td align="left">Supplemental Data Service Provider (SDSP)</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> <tr> <td align="left">27</td> <td align="left">Crowd Sourced RID Finder</td> <tdalign="left">This RFC</td>align="left">RFC 9886</td> </tr> </tbody> </table> </section> </section> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <section anchor="dns-operational-registration-considerations"> <name>DNS Operational&and Registration Considerations</name> <!-- [rfced] For clarity, we suggest updating the text as follows. Please review and let us know if the text may be updated. Original: 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 except when national regulations prevent it. Perhaps A: These components interface the DIME with the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate except when national regulations prevent it. Perhaps B: These components connect the DIME with the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate except when national regulations prevent it. --> <t>The Registrar and Registry are commonly used concepts in the DNS. These components interface the DIME into the DNS hierarchy and thus operationSHOULD<bcp14>SHOULD</bcp14> follow best common practices, specifically in security (such as running DNSSEC) as appropriate except when national regulations prevent it. <xref target="BCP237"/> provides suitable guidance.</t> <t>If DNSSEC is used, a DNSSEC Practice StatementSHOULD<bcp14>SHOULD</bcp14> be developed and published. ItSHOULD<bcp14>SHOULD</bcp14> explain how DNSSEC has been deployed and what security measures are in place. <xref target="RFC6841"/> documents aFrameworkframework for DNSSECPoliciespolicies and DNSSEC Practice Statements. A self-signed entity(i.e.(i.e., an entity that self-signeditits certificate as part of the HHIT RRType)MUST<bcp14>MUST</bcp14> use DNSSEC.</t> <t>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 that registry-registrar activity will use the Extensible Provisioning Protocol (EPP) <xref target="STD69"/> or equivalent. The registrySHOULD<bcp14>SHOULD</bcp14> provide a lookup service such as RDAP <xref target="STD95"/> or equivalent to publish public information about registered domain names.</t> <t>Decisions about DNS or registry best practices and other operational matters that influence securitySHOULD<bcp14>SHOULD</bcp14> be made by the CAA, ideally in consultation with local stakeholders.</t> <t>The guidance above is intended to reduce the likelihood of interoperability problems and minimize security and stability concerns. For instance, validation and authentication of DNS responses depends on DNSSEC. If this is not used, entities using DRIP will be vulnerable to DNS spoofing attacks and could be exposed to bogus data. DRIP DNS responses that have not been validated by DNSSEC could contain bogus datawhichthat have the potential to create serious security problems and operational concerns for DRIP entities. These threats includedenial of servicedenial-of-service attacks, replay attacks, impersonation or cloning of UAVs, hijacking of DET registrations, injection of corruptmetadatametadata, and compromising established trust architecture/relationships. Some regulatory and legal considerations are expected to be simplified by providing a lookup service for access to public information about registered domain names for DETs.</t> <t>When DNSSEC is not in use, due to the length of the ORCHID hash selected for DETs (<xref section="3.5" sectionFormat="of" target="RFC9374"/>), clientsMUST<bcp14>MUST</bcp14> "walk" the tree of certificates locating each certificate by performing DNS lookups of HHIT RRTypes for each DET verifying inclusion into the hierarchy. The collection of these certificates (which provide both signature protection from the parent entity and the public key of the entity) is the only way without DNSSEC to prove valid registration.</t> <t>The contents of the BRID RRType <tt>auth</tt> key, containing Endorsements as described in <xref section="4.2" sectionFormat="of" target="RFC9575"/>, are a shadow of the X.509 certificate found in the HHIT RRType. The validation of these Endorsements follow the guidelines written in <xref section="6.4.2" sectionFormat="of" target="RFC9575"/> for Broadcast RID Observers and when presentMUST<bcp14>MUST</bcp14> also be validated.</t> </section> <section anchor="det-public-key-exposure"> <name>DET&and Public Key Exposure</name> <t>DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. <xref target="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).</t> <t>When practical, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that no RRTypes under a DET's specific domain name be published unless and until it is required for use by other parties. Such action would cause at least the HHIT RRType to not be in the DNS, protecting the public key in the certificate from being exposed before its needed. The combination of this "just in time" publishing mechanism and DNSSEC is out of scope for this document.</t> <t>Optimally this requires that the UAS somehow signal to 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.</t> </section> </section><section anchor="acknowledgements"> <name>Acknowledgements</name> <t>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.</t> </section></middle> <back> <displayreference target="I-D.ietf-drip-dki" to="drip-dki"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC4648"> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <date month="October" year="2006"/> <abstract> <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/> </reference> <reference anchor="RFC8949"> <front> <title>Concise Binary Object Representation (CBOR)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="December" year="2020"/> <abstract> <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> <reference anchor="RFC9374"> <front> <title>DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)</title> <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/> <author fullname="S. Card" initials="S." surname="Card"/> <author fullname="A. Wiethuechter" initials="A." surname="Wiethuechter"/> <author fullname="A. Gurtov" initials="A." surname="Gurtov"/> <date month="March" year="2023"/> <abstract> <t>This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking.</t> <t>Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement.</t> <t>This document updates RFCs 7401 and 7343.</t> </abstract> </front> <seriesInfo name="RFC" value="9374"/> <seriesInfo name="DOI" value="10.17487/RFC9374"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9374.xml"/> <reference anchor="F3411" target="https://www.astm.org/f3411-22a.html"> <front> <title>Standard Specification for Remote ID and Tracking</title> <author> <organization>ASTM International</organization> </author> <date year="2022" month="July"/> </front> <seriesInfo name="ASTM" value="F3411-22A"/> <seriesInfo name="DOI" value="10.1520/F3411-22A"/> </reference><reference anchor="ISO3166-1" target="https://www.iso.org/iso-3166-country-codes.html"> <front> <title>Codes for the representation of names of countries and their subdivisions</title> <author> <organization>International Standards Organization (ISO)</organization> </author> <date year="2020" month="August"/> </front> <seriesInfo name="ISO" value="3166-1:2020"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="drip-dki"> <front> <title>The DRIP DET public Key Infrastructure</title> <author fullname="Robert Moskowitz" initials="R." surname="Moskowitz"> <organization>HTT Consulting</organization> </author> <author fullname="Stuart W. Card" initials="S. W." surname="Card"> <organization>AX Enterprize, LLC</organization> </author> <date day="22" month="April" year="2025"/> <abstract> <t><!-- [rfced] [ISO-3166-2] Please review. TheDRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-drip-dki-08"/> </reference> <referencegroup anchor="BCP237" target="https://www.rfc-editor.org/info/bcp237"> <reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rfc9364"> <front> <title>DNS Security Extensions (DNSSEC)</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="February" year="2023"/> <abstract> <t>This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose isURL below goes toprovideasinglepage titled “ISO 3166 Country Codes”, but this referencefor other documents that wantappears torefer to DNSSEC.</t> </abstract> </front> <seriesInfo name="BCP" value="237"/> <seriesInfo name="RFC" value="9364"/> <seriesInfo name="DOI" value="10.17487/RFC9364"/> </reference> </referencegroup> <referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/std13"> <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"> <front> <title>Domain names - concepts and facilities</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1034"/> <seriesInfo name="DOI" value="10.17487/RFC1034"/> </reference> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035"> <front> <title>Domain names - implementation and specification</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> </referencegroup> <referencegroup anchor="STD69" target="https://www.rfc-editor.org/info/std69"> <reference anchor="RFC5730" target="https://www.rfc-editor.org/info/rfc5730"> <front> <title>Extensible Provisioning Protocol (EPP)</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <date month="August" year="2009"/> <abstract> <t>This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="69"/> <seriesInfo name="RFC" value="5730"/> <seriesInfo name="DOI" value="10.17487/RFC5730"/> </reference> <reference anchor="RFC5731" target="https://www.rfc-editor.org/info/rfc5731"> <front> <title>Extensible Provisioning Protocol (EPP) Domain Name Mapping</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <date month="August" year="2009"/> <abstract> <t>This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as appliedbe specifically todomain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="69"/> <seriesInfo name="RFC" value="5731"/> <seriesInfo name="DOI" value="10.17487/RFC5731"/> </reference> <reference anchor="RFC5732" target="https://www.rfc-editor.org/info/rfc5732"> <front> <title>Extensible Provisioning Protocol (EPP) Host Mapping</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <date month="August" year="2009"/> <abstract> <t>This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and managementPart 1 ofInternet host names stored in a shared central repository. Specified in XML,ISO 3166 (ISO 3166-1). We found themapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="69"/> <seriesInfo name="RFC" value="5732"/> <seriesInfo name="DOI" value="10.17487/RFC5732"/> </reference> <reference anchor="RFC5733" target="https://www.rfc-editor.org/info/rfc5733"> <front> <title>Extensible Provisioning Protocol (EPP) Contact Mapping</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <date month="August" year="2009"/> <abstract> <t>This document describes an Extensible Provisioning Protocol (EPP) mappingfollowing URL for theprovisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="69"/> <seriesInfo name="RFC" value="5733"/> <seriesInfo name="DOI" value="10.17487/RFC5733"/> </reference> <reference anchor="RFC5734" target="https://www.rfc-editor.org/info/rfc5734"> <front> <title>Extensible Provisioning Protocol (EPP) Transport over TCP</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <date month="August" year="2009"/> <abstract> <t>This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="69"/> <seriesInfo name="RFC" value="5734"/> <seriesInfo name="DOI" value="10.17487/RFC5734"/> </reference> </referencegroup> <referencegroup anchor="STD95" target="https://www.rfc-editor.org/info/std95"> <reference anchor="RFC7480" target="https://www.rfc-editor.org/info/rfc7480"> <front> <title>HTTP Usage in the Registration Data Access Protocol (RDAP)</title> <author fullname="A. Newton" initials="A." surname="Newton"/> <author fullname="B. Ellacott" initials="B." surname="Ellacott"/> <author fullname="N. Kong" initials="N." surname="Kong"/> <date month="March" year="2015"/> <abstract> <t>This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purposemost up-to-date version ofthis document isISO 3166-1 (ISO 3166-1:2020): https://www.iso.org/standard/72482.html Would you like toclarify the use of standard HTTP mechanisms forupdate thisapplication.</t> </abstract> </front> <seriesInfo name="STD" value="95"/> <seriesInfo name="RFC" value="7480"/> <seriesInfo name="DOI" value="10.17487/RFC7480"/> </reference> <reference anchor="RFC7481" target="https://www.rfc-editor.org/info/rfc7481"> <front> <title>Security Services for the Registration Data Access Protocol (RDAP)</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <author fullname="N. Kong" initials="N." surname="Kong"/> <date month="March" year="2015"/> <abstract> <t>The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.</t> </abstract> </front> <seriesInfo name="STD" value="95"/> <seriesInfo name="RFC" value="7481"/> <seriesInfo name="DOI" value="10.17487/RFC7481"/> </reference> <reference anchor="RFC9082" target="https://www.rfc-editor.org/info/rfc9082"> <front> <title>Registration Data Access Protocol (RDAP) Query Format</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <author fullname="A. Newton" initials="A." surname="Newton"/> <date month="June" year="2021"/> <abstract> <t>This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482.</t> </abstract> </front> <seriesInfo name="STD" value="95"/> <seriesInfo name="RFC" value="9082"/> <seriesInfo name="DOI" value="10.17487/RFC9082"/> </reference> <reference anchor="RFC9083" target="https://www.rfc-editor.org/info/rfc9083"> <front> <title>JSON Responses for the Registration Data Access Protocol (RDAP)</title> <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/> <author fullname="A. Newton" initials="A." surname="Newton"/> <date month="June" year="2021"/> <abstract> <t>This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.</t> </abstract> </front> <seriesInfo name="STD" value="95"/> <seriesInfo name="RFC" value="9083"/> <seriesInfo name="DOI" value="10.17487/RFC9083"/> </reference> <reference anchor="RFC9224" target="https://www.rfc-editor.org/info/rfc9224"> <front> <title>Finding the Authoritative Registration Data Access Protocol (RDAP) Service</title> <author fullname="M. Blanchet" initials="M." surname="Blanchet"/> <date month="March" year="2022"/> <abstract> <t>This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484.</t> </abstract> </front> <seriesInfo name="STD" value="95"/> <seriesInfo name="RFC" value="9224"/> <seriesInfo name="DOI" value="10.17487/RFC9224"/> </reference> </referencegroup> <referencegroup anchor="STD88" target="https://www.rfc-editor.org/info/std88"> <reference anchor="RFC3596" target="https://www.rfc-editor.org/info/rfc3596"> <front> <title>DNS Extensions to Support IP Version 6</title> <author fullname="S. Thomson" initials="S." surname="Thomson"/> <author fullname="C. Huitema" initials="C." surname="Huitema"/> <author fullname="V. Ksinant" initials="V." surname="Ksinant"/> <author fullname="M. Souissi" initials="M." surname="Souissi"/> <date month="October" year="2003"/> <abstract> <t>This document defines the changes that needreference tobe madepoint to theDomain Name System (DNS) to support hosts running IPmost up-to-date version6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="88"/> <seriesInfo name="RFC" value="3596"/> <seriesInfo name="DOI" value="10.17487/RFC3596"/> </reference> </referencegroup> <reference anchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overviewof ISO 3166-1? Or would you like thisapproach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC6841"> <front> <title>A Framework for DNSSEC Policies and DNSSEC Practice Statements</title> <author fullname="F. Ljunggren" initials="F." surname="Ljunggren"/> <author fullname="AM. Eklund Lowinder" initials="AM." surname="Eklund Lowinder"/> <author fullname="T. Okubo" initials="T." surname="Okubo"/> <date month="January" year="2013"/> <abstract> <t>This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.</t> <t>In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6841"/> <seriesInfo name="DOI" value="10.17487/RFC6841"/> </reference> <reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constantsreference toidentify various protocol parameters. To ensure that the values in these fields do not have conflicting uses andpoint topromote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describingtheconditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a frameworkmore general page forthe documentation of these guidelines by specification authors, in order to assure that the provided guidanceISO 3166? Current: [ISO3166-1] ISO, "Codes for theIANA Considerations is clear and addresses the various issues that are likely in the operationrepresentation ofa registry.</t> <t>This is the third editionnames ofthis document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/> <author fullname="C. Vigano" initials="C." surname="Vigano"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2019"/> <abstract> <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messagescountries anddata formats that use CBOR or JSON.</t> </abstract> </front> <seriesInfo name="RFC" value="8610"/> <seriesInfo name="DOI" value="10.17487/RFC8610"/> </reference>their subdivisions - Part 1: Country code", ISO 3166-1:2020, August 2020, <https://www.iso.org/iso-3166-country-codes.html>. Perhaps: [ISO-3166] ISO, "Country Codes", ISO 3166, <https://www.iso.org/iso-3166-country-codes.html>. --> <referenceanchor="RFC9153">anchor="ISO3166-1" target="https://www.iso.org/iso-3166-country-codes.html"> <front><title>Drone Remote Identification Protocol (DRIP) Requirements and Terminology</title> <author fullname="S. Card" initials="S." role="editor" surname="Card"/> <author fullname="A. Wiethuechter" initials="A." surname="Wiethuechter"/> <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/> <author fullname="A. Gurtov" initials="A." surname="Gurtov"/> <date month="February" year="2022"/> <abstract> <t>This document defines terminology and requirements<title>Codes forsolutions produced bytheDrone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiationrepresentation ofidentity-based network sessions supporting UAS applications). DRIP will facilitate usenames ofexisting Internet resources to support RID and to enable enhanced related services, and it will enable onlinecountries andoffline verification that RID information is trustworthy.</t> </abstract> </front> <seriesInfo name="RFC" value="9153"/> <seriesInfo name="DOI" value="10.17487/RFC9153"/> </reference> <reference anchor="RFC9434"> <front> <title>Drone Remote Identification Protocol (DRIP) Architecture</title> <author fullname="S. Card" initials="S." surname="Card"/> <author fullname="A. Wiethuechter" initials="A." surname="Wiethuechter"/> <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/> <author fullname="S. Zhao" initials="S." role="editor" surname="Zhao"/> <author fullname="A. Gurtov" initials="A." surname="Gurtov"/>their subdivisions - Part 1: Country code</title> <author> <organization>ISO</organization> </author> <datemonth="July" year="2023"/> <abstract> <t>This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153).</t> </abstract>year="2020" month="August"/> </front> <seriesInfoname="RFC" value="9434"/> <seriesInfo name="DOI" value="10.17487/RFC9434"/>name="ISO" value="3166-1:2020"/> </reference><reference anchor="RFC9575"> <front> <title>DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)</title> <author fullname="A. Wiethuechter" initials="A." role="editor" surname="Wiethuechter"/> <author fullname="S. Card" initials="S." surname="Card"/> <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/> <date month="June" year="2024"/> <abstract> <t>The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messages were signed by the registered owner<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <!-- [drip-dki] draft-ietf-drip-dki-09 IESG State: I-D Exists as ofthe DRIP Entity Tag (DET) claimed.</t> </abstract> </front> <seriesInfo name="RFC" value="9575"/> <seriesInfo name="DOI" value="10.17487/RFC9575"/> </reference>10/22/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-dki.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.237.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.13.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.69.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.95.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.88.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6841.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9153.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9434.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9575.xml"/> </references> </references><?line 550?><section anchor="example-zone-files-rrtype-contents"> <name>Example Zone Files&and RRType Contents</name> <t>An example zone file <tt>ip6.arpa.</tt>, run by IANA, is not shown. It would contain NS RRTypes to delegate to a respective RAA. To avoid any future collisions with production deployments an apex of <tt>ip6.example.com.</tt> is used instead of <tt>ip6.arpa.</tt>. All hexadecimal strings in the examples are broken into the lengths of a word, for document formatting purposes.</t> <t>An RAA with a HID of <tt>RAA=16376, HDA=0</tt> and HDA with a the HID <tt>RAA=16376, HDA=10</tt> were used in the examples.</t> <section anchor="example-raa"> <name>Example RAA</name> <section anchor="raa-hhits"> <name>Authentication HHIT</name> <figure anchor="raa-rr-zone"> <name>RAA Auth HHIT RRType Example</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ $ORIGIN 5.0.0.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com. 7.b.0.a.1.9.e.1.7.5.1.a.0.6.e.5. IN HHIT ( gwppM2ZmOCAwMDAwWQFGMIIBQjCB9aAD AgECAgE1MAUGAytlcDArMSkwJwYDVQQD DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx NTcxZTkxYTBiNzAeFw0yNTA0MDkyMDU2 MjZaFw0yNTA0MDkyMTU2MjZaMB0xGzAZ BgNVBAMMEkRSSVAtUkFBLUEtMTYzNzYt MDAqMAUGAytlcAMhAJmQ1bBLcqGAZtQJ K1LH1JlPt8Fr1+jB9ED/qNBP8eE/o0ww SjAPBgNVHRMBAf8EBTADAQH/MDcGA1Ud EQEB/wQtMCuHECABAD/+AAAFXmChVx6R oLeGF2h0dHBzOi8vcmFhLmV4YW1wbGUu Y29tMAUGAytlcANBALUPjhIB3rwqXQep r9/VDB+hhtwuWZIw1OUkEuDrF6DCkgc7 5widXnXa5/uDfdKL7dZ83mPHm2Tf32Dv b8AzEw8=) ]]></artwork>)]]></sourcecode> </figure> <t><xref target="raa-rr-cbor"/> shows the CBOR decoded RDATA in the HHIT RRType found in <xref target="raa-rr-zone"/>.</t> <figure anchor="raa-rr-cbor"> <name>2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded HHIT RRType CBOR</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ [ 10, # Reserved (RAA Auth from DKI) "3ff8 0000", h'308201423081F5A00302010202013530 0506032B6570302B312930270603550403 0C20323030313030336666653030303030 3535653630613135373165393161306237 301E170D3235303430393230353632365A 170D3235303430393231353632365A301D 311B301906035504030C12445249502D52 41412D412D31363337362D30302A300506 032B65700321009990D5B04B72A18066D4 092B52C7D4994FB7C16BD7E8C1F440FFA8 D04FF1E13FA34C304A300F0603551D1301 01FF040530030101FF30370603551D1101 01FF042D302B87102001003FFE0000055E 60A1571E91A0B7861768747470733A2F2F 7261612E6578616D706C652E636F6D3005 06032B6570034100B50F8E1201DEBC2A5D 07A9AFDFD50C1FA186DC2E599230D4E524 12E0EB17A0C292073BE7089D5E75DAE7FB 837DD28BEDD67CDE63C79B64DFDF60EF6F C033130F'] ]]></artwork>]]]></sourcecode> </figure> <t><xref target="raa-rr-cert"/> shows the decoded DER X.509 found in <xref target="raa-rr-cbor"/>.</t> <figure anchor="raa-rr-cert"> <name>2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded Certificate</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ Certificate: Data: Version: 3 (0x2) Serial Number: 53 (0x35) Signature Algorithm: ED25519 Issuer: CN = 2001003ffe0000055e60a1571e91a0b7 Validity Not Before: Apr 9 20:56:26 2025 GMT Not After : Apr 9 21:56:26 2025 GMT Subject: CN = DRIP-RAA-A-16376-0 Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 99:90:d5:b0:4b:72:a1:80:66:d4:09:2b:52:c7:d4: 99:4f:b7:c1:6b:d7:e8:c1:f4:40:ff:a8:d0:4f:f1: e1:3f X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Alternative Name: critical IP Address:2001:3F:FE00:5:5E60:A157:1E91:A0B7, URI:https://raa.example.com Signature Algorithm: ED25519 Signature Value: b5:0f:8e:12:01:de:bc:2a:5d:07:a9:af:df:d5:0c:1f:a1:86: dc:2e:59:92:30:d4:e5:24:12:e0:eb:17:a0:c2:92:07:3b:e7: 08:9d:5e:75:da:e7:fb:83:7d:d2:8b:ed:d6:7c:de:63:c7:9b:64:df:df:60:ef:6f:c0:33:13:0f ]]></artwork>64:df:df:60:ef:6f:c0:33:13:0f]]></sourcecode> </figure> </section> <section anchor="delegation-of-hda"> <name>Delegation of HDA</name> <figure> <name>HDA Delegation Example</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ $ORIGIN c.d.f.f.3.0.0.1.0.0.2.ip6.example.com. a.0.0. IN NSns1.hda-10.example.com ]]></artwork>ns1.hda-10.example.com]]></sourcecode> </figure> </section> </section> <section anchor="example-hda"> <name>Example HDA</name> <section anchor="hda-hhits"> <name>Authentication&and Issue HHITs</name> <figure anchor="hda-rr-zone"> <name>HDA Auth/Issue HHIT RRType Example</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ $ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com. 0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. IN HHIT ( gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD AgECAgFfMAUGAytlcDArMSkwJwYDVQQD DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt MTAwKjAFBgMrZXADIQDOaB424RQa61YN bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV HREBAf8ELTArhxAgAQA//gAKBWYV7kXU JwmghhdodHRwczovL3JhYS5leGFtcGxl LmNvbTAFBgMrZXADQQAhMpOSOmgMkJY1 f+B9nTgawUjK4YEERBtczMknHDkOowX0 ynbaLN60TYe9hqN6+CJ3SN8brJke3hpM gorvhDkJ ) 8.2.e.6.5.2.b.6.7.3.4.d.e.0.6.2.5.0. IN HHIT ( gw9pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD AgECAgFYMAUGAytlcDArMSkwJwYDVQQD DCAyMDAxMDAzZmZlMDAwYTA1NjYxNWVl NDVkNDI3MDlhMDAeFw0yNTA0MDkyMTA1 MTRaFw0yNTA0MDkyMjA1MTRaMB4xHDAa BgNVBAMME0RSSVAtSERBLUktMTYzNzYt MTAwKjAFBgMrZXADIQCCM/2utQaLwUhZ 0ROg7fz43AeBTj3Sdl5rW4LgTQcFl6NM MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV HREBAf8ELTArhxAgAQA//gAKBSYO1Ddr JW4ohhdodHRwczovL2hkYS5leGFtcGxl LmNvbTAFBgMrZXADQQBa8lZyftxHJqDF Vgv4Rt+cMUmc8aQwet4UZdO3yQOB9uq4 sLVAScaZCWjC0nmeRkgVRhize1esfyi3 RRU44IAE) ]]></artwork>)]]></sourcecode> </figure> <t><xref target="hdaa-rr-cbor"/> shows the CBOR decoded RDATA in the HHIT RRType found in <xref target="hda-rr-zone"/>.</t> <figure anchor="hdaa-rr-cbor"> <name>2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded HHIT RRType CBOR</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ [ 14, # Reserved (HDA Auth from DKI) "3ff8 000a", h'308201433081F6A00302010202015F30 0506032B6570302B312930270603550403 0C20323030313030336666653030303030 3535653630613135373165393161306237 301E170D3235303430393231303331395A 170D3235303430393232303331395A301E 311C301A06035504030C13445249502D48 44412D412D31363337362D3130302A3005 06032B6570032100CE681E36E1141AEB56 0D6E76BC796B7B7CB454E463CCB1F12DE3 0A380101803FA34C304A300F0603551D13 0101FF040530030101FF30370603551D11 0101FF042D302B87102001003FFE000A05 6615EE45D42709A0861768747470733A2F 2F7261612E6578616D706C652E636F6D30 0506032B6570034100213293923A680C90 96357FE07D9D381AC148CAE18104441B5C CCC9271C390EA305F4CA76DA2CDEB44D87 BD86A37AF8227748DF1BAC991EDE1A4C82 8AEF843909'] ]]></artwork>]]]></sourcecode> </figure> <t><xref target="hdaa-rr-cert"/> shows the decoded DER X.509 found in <xref target="hdaa-rr-cbor"/>.</t> <figure anchor="hdaa-rr-cert"> <name>2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded Certificate</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ Certificate: Data: Version: 3 (0x2) Serial Number: 95 (0x5f) Signature Algorithm: ED25519 Issuer: CN = 2001003ffe0000055e60a1571e91a0b7 Validity Not Before: Apr 9 21:03:19 2025 GMT Not After : Apr 9 22:03:19 2025 GMT Subject: CN = DRIP-HDA-A-16376-10 Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: ce:68:1e:36:e1:14:1a:eb:56:0d:6e:76:bc:79:6b: 7b:7c:b4:54:e4:63:cc:b1:f1:2d:e3:0a:38:01:01: 80:3f X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Alternative Name: critical IP Address:2001:3F:FE00:A05:6615:EE45:D427:9A0, URI:https://raa.example.com Signature Algorithm: ED25519 Signature Value: 21:32:93:92:3a:68:0c:90:96:35:7f:e0:7d:9d:38:1a:c1:48: ca:e1:81:04:44:1b:5c:cc:c9:27:1c:39:0e:a3:05:f4:ca:76: da:2c:de:b4:4d:87:bd:86:a3:7a:f8:22:77:48:df:1b:ac:99:1e:de:1a:4c:82:8a:ef:84:39:09 ]]></artwork>1e:de:1a:4c:82:8a:ef:84:39:09]]></sourcecode> </figure> <t><xref target="hdai-rr-cbor"/> shows the CBOR decoded RDATA in the HHIT RRType found in <xref target="hda-rr-zone"/>.</t> <figure anchor="hdai-rr-cbor"> <name>2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded HHIT RRType CBOR</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ [ 15, # Reserved (HDA Issue from DKI) "3ff8 000a", h'308201433081F6A00302010202015830 0506032B6570302B312930270603550403 0C20323030313030336666653030306130 3536363135656534356434323730396130 301E170D3235303430393231303531345A 170D3235303430393232303531345A301E 311C301A06035504030C13445249502D48 44412D492D31363337362D3130302A3005 06032B65700321008233FDAEB5068BC148 59D113A0EDFCF8DC07814E3DD2765E6B5B 82E04D070597A34C304A300F0603551D13 0101FF040530030101FF30370603551D11 0101FF042D302B87102001003FFE000A05 260ED4376B256E28861768747470733A2F 2F6864612E6578616D706C652E636F6D30 0506032B65700341005AF256727EDC4726 A0C5560BF846DF9C31499CF1A4307ADE14 65D3B7C90381F6EAB8B0B54049C6990968 C2D2799E4648154618B37B57AC7F28B745 1538E08004'] ]]></artwork>]]]></sourcecode> </figure> <t><xref target="hdai-rr-cert"/> shows the decoded DER X.509 found in <xref target="hdai-rr-cbor"/>.</t> <figure anchor="hdai-rr-cert"> <name>2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ Certificate: Data: Version: 3 (0x2) Serial Number: 88 (0x58) Signature Algorithm: ED25519 Issuer: CN = 2001003ffe000a056615ee45d42709a0 Validity Not Before: Apr 9 21:05:14 2025 GMT Not After : Apr 9 22:05:14 2025 GMT Subject: CN = DRIP-HDA-I-16376-10 Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 82:33:fd:ae:b5:06:8b:c1:48:59:d1:13:a0:ed:fc: f8:dc:07:81:4e:3d:d2:76:5e:6b:5b:82:e0:4d:07: 05:97 X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Alternative Name: critical IP Address:2001:3F:FE00:A05:260E:D437:6B25:6E28, URI:https://hda.example.com Signature Algorithm: ED25519 Signature Value: 5a:f2:56:72:7e:dc:47:26:a0:c5:56:0b:f8:46:df:9c:31:49: 9c:f1:a4:30:7a:de:14:65:d3:b7:c9:03:81:f6:ea:b8:b0:b5: 40:49:c6:99:09:68:c2:d2:79:9e:46:48:15:46:18:b3:7b:57:ac:7f:28:b7:45:15:38:e0:80:04 ]]></artwork>ac:7f:28:b7:45:15:38:e0:80:04]]></sourcecode> </figure> </section> <section anchor="registratant-hhit-brid"> <name>Registratant HHIT&and BRID</name> <figure anchor="uas-rr-zone"> <name>Registrant HHIT/BRID RRType Example</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ $ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com. 2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN HHIT ( gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD AgECAgFUMAUGAytlcDArMSkwJwYDVQQD DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0 Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5 +drcW88GHqxPDOp56Oh3+qM7MDkwNwYD VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp mkvGsoYXaHR0cHM6Ly9oZGEuZXhhbXBs ZS5jb20wBQYDK2VwA0EA0DbcdngC7/BB /aLjZmLieo0ZFCDbd/KIxAy+3X2KtT4J todVxRMPAkN6o008gacbNfTG8p9npEcD eYhesl2jBQ== ) 2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN BRID ( owAAAYIEUQEgAQA//gAKBRMIJGmaS8ay AogFWIkB+t72Zwrt9mcgAQA//gAABV5g oVcekaC3mZDVsEtyoYBm1AkrUsfUmU+3 wWvX6MH0QP+o0E/x4T8gAQA//gAABV5g oVcekaC3vC9m1JguvXt7W2o4wxPumaT1 IP3TQN3fQP28hpInSIlsSwq8UCNjm2ad 7pdTvm2EqfOJQNPKClvRZm4qTO5FDAVY iQGX4PZnp+72ZyABAD/+AAoFZhXuRdQn CaDOaB424RQa61YNbna8eWt7fLRU5GPM sfEt4wo4AQGAPyABAD/+AAAFXmChVx6R oLfv3q+mLRB3ya5TmjY8+3CzdoDZT9RZ +XpN5hDiA6JyyxBJvUewxLzPNhTXQp8v ED71XAE82tMmt3fB4zbzWNQLBViJAQrh 9mca7/ZnIAEAP/4ACgUmDtQ3ayVuKIIz /a61BovBSFnRE6Dt/PjcB4FOPdJ2Xmtb guBNBwWXIAEAP/4ACgVmFe5F1CcJoIjy CriJCxAyAWTOHPmlHL02MKSpsHviiTze qwBH9K/Rrz41CYix9HazAIOAZO8FcfU5 M+WLLJZoaQWBHnMbTQwFWIkB3OL2Z+zw 9mcgAQA//gAKBRMIJGmaS8ayyS4vnZfo lg+bXxZU+LCQOfna3FvPBh6sTwzqeejo d/ogAQA//gAKBSYO1DdrJW4ogOfc8jTi mYLmTOOyFZoUx2jOOwtB1jnqUJr6bYaw MoPrR3MlKGBGWsVz1yXNqUURoCqYdwsY e61vd5i6YJqnAQ==) ]]></artwork>)]]></sourcecode> </figure> <t><xref target="uas-rr-cbor"/> shows the CBOR decoded RDATA in the HHIT RRType found in <xref target="uas-rr-zone"/>.</t> <figure anchor="uas-rr-cbor"> <name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded HHIT RRType CBOR</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ [ 18, # Uncrewed Aircraft System (UAS) "3ff8 000a", h'308201143081C7A00302010202015430 0506032B6570302B312930270603550403 0C20323030313030336666653030306130 3532363065643433373662323536653238 301E170D3235303430393231313330305A 170D3235303430393232313330305A3000 302A300506032B6570032100C92E2F9D97 E8960F9B5F1654F8B09039F9DADC5BCF06 1EAC4F0CEA79E8E877FAA33B3039303706 03551D110101FF042D302B87102001003F FE000A05130824699A4BC6B28617687474 70733A2F2F6864612E6578616D706C652E 636F6D300506032B6570034100D036DC76 7802EFF041FDA2E36662E27A8D191420DB 77F288C40CBEDD7D8AB53E09B68755C513 0F02437AA34D3C81A71B35F4C6F29F67A4 470379885EB25DA305'] ]]></artwork>]]]></sourcecode> </figure> <t><xref target="uas-rr-cert"/> shows the decoded DER X.509 found in <xref target="uas-rr-cbor"/>.</t> <figure anchor="uas-rr-cert"> <name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded Certificate</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ Certificate: Data: Version: 3 (0x2) Serial Number: 84 (0x54) Signature Algorithm: ED25519 Issuer: CN = 2001003ffe000a05260ed4376b256e28 Validity Not Before: Apr 9 21:13:00 2025 GMT Not After : Apr 9 22:13:00 2025 GMT Subject: Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: c9:2e:2f:9d:97:e8:96:0f:9b:5f:16:54:f8:b0:90: 39:f9:da:dc:5b:cf:06:1e:ac:4f:0c:ea:79:e8:e8: 77:fa X509v3 extensions: X509v3 Subject Alternative Name: critical IP Address:2001:3F:FE00:A05:1308:2469:9A4B:C6B2, URI:https://hda.example.com Signature Algorithm: ED25519 Signature Value: d0:36:dc:76:78:02:ef:f0:41:fd:a2:e3:66:62:e2:7a:8d:19: 14:20:db:77:f2:88:c4:0c:be:dd:7d:8a:b5:3e:09:b6:87:55: c5:13:0f:02:43:7a:a3:4d:3c:81:a7:1b:35:f4:c6:f2:9f:67:a4:47:03:79:88:5e:b2:5d:a3:05 ]]></artwork>a4:47:03:79:88:5e:b2:5d:a3:05]]></sourcecode> </figure> <t><xref target="uas-rr-brid"/> shows the CBOR decoded RDATA of the BRID RRType in <xref target="uas-rr-zone"/>.</t> <figure anchor="uas-rr-brid"> <name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID RRType CBOR</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ { 0: 0, 1: [4, h'012001003FFE000A05130824699A4BC6B2'], 2: [ 5, h'01FADEF6670AEDF6672001003FFE0000 055E60A1571E91A0B79990D5B04B72A180 66D4092B52C7D4994FB7C16BD7E8C1F440 FFA8D04FF1E13F2001003FFE0000055E60 A1571E91A0B7BC2F66D4982EBD7B7B5B6A 38C313EE99A4F520FDD340DDDF40FDBC86 922748896C4B0ABC5023639B669DEE9753 BE6D84A9F38940D3CA0A5BD1666E2A4CEE 450C', 5, h'0197E0F667A7EEF6672001003FFE000A 056615EE45D42709A0CE681E36E1141AEB 560D6E76BC796B7B7CB454E463CCB1F12D E30A380101803F2001003FFE0000055E60 A1571E91A0B7EFDEAFA62D1077C9AE539A 363CFB70B37680D94FD459F97A4DE610E2 03A272CB1049BD47B0C4BCCF3614D7429F 2F103EF55C013CDAD326B777C1E336F358 D40B', 5, h'010AE1F6671AEFF6672001003FFE000A 05260ED4376B256E288233FDAEB5068BC1 4859D113A0EDFCF8DC07814E3DD2765E6B 5B82E04D0705972001003FFE000A056615 EE45D42709A088F20AB8890B10320164CE 1CF9A51CBD3630A4A9B07BE2893CDEAB00 47F4AFD1AF3E350988B1F476B300838064 EF0571F53933E58B2C96686905811E731B 4D0C', 5, h'01DCE2F667ECF0F6672001003FFE000A 05130824699A4BC6B2C92E2F9D97E8960F 9B5F1654F8B09039F9DADC5BCF061EAC4F 0CEA79E8E877FA2001003FFE000A05260E D4376B256E2880E7DCF234E29982E64CE3 B2159A14C768CE3B0B41D639EA509AFA6D 86B03283EB4773252860465AC573D725CD A94511A02A98770B187BAD6F7798BA609A A701' ]} ]]></artwork>}]]></sourcecode> </figure> </section> </section> </section> <section anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>Thanks to <contact fullname="Stuart Card"/> (AX Enterprize, LLC) and <contact fullname="Bob Moskowitz"/> (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundation for the content and processes of this architecture and document.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+29aXfbSLIm/F2/AlM1p0u62rATwD01MyBBWrK1L7blnj5t kARFWCRBA6Qo2a757RNLJpAgqcV1697T75yXrrJJIJFLZGREPJGRgd3d3Y1e 1k8nt4E2nw12vY2NWTobJYEWXRyeae0J/HrUruLbQksn2myYaFE2juHrSTxO tMvHYpaMN+JuN0/u4ZH2FZaKTi43+llvAiUCrZ/Hg9lumkDd/Tyd7ubJbVrM 8jQpdi1roxfPktssfwy0Ytbf2EineaDN8nkxM3Xd182NOE/iQDuczJJ8ksw2 FrdYYTrVPmT5HfRZe5Nn8+nG3aIqsxthg1ixqLOYxZP+P+NRNoHePCbFxjQN tL/Pst6OVmT5LE8GBXx7HPOXXjYeJ5NZ8Y+NjXg+G2Z5sLGraVqeIUmSfjrL 8g34DcMsAi3c0z7AyIbzpDeE1ukGjzrsx+PVe1kO/Q8/IlWTfJqn35Id7eio RfeAJkkCfbZ9u6G1sBd5L41HWpSn9wmV6MFMBNoNjPw+HY34GlIzmwTayQ0X yfrQuGHZviN+zyczpO71ZUgXEpi7UaDF0L29hdK9/xU/JGWn9oAINGoa5Ns9 7SJJ+8rg3qbj6hKN6eKqc6yNRtPaSC5nWjjp58mi0A6yeaEOwvJM7QAGAVM4 yybaRRb3d7Q3o7i4zRbaZS+bjWDOlBG9cQzNbh4tjemdOqQv6fh/5YOeoVsO 9X9jkuXjeAbEC6jYRadlu7YXaL9q3bhIXFte9Xzbx6u9rphauOZbDRuvEcf2 k5mm7e5qV6fR6WabWGAL+W0gG/ifG/Rcx7INgxvTNLGILpH54ryvXU6TXjpI gS1hvjR4FCg4zmaJdhhpUES7yuMecrR4XPKeJj675TfJRZdXx4Lnqcp4JBuO 81uk/nA2mxbB/v5isdiLi9l4Dx7bH2AXd00z3hvOxvKJPqxBmNT56FEzddMU V4sE12gKo6x6gY0GPE6oJCyvR6eHwHX6nuGY+n799uHlqWW47u4yYVowrwXR AWVKnkzzpAAOZPJkA+K0Ar/wdENXiExQOM21Yt7tp/dpAWWL1xKsRqtyXgrt NL+NJ+k3bngTurv1DCHTIiM6wr+7NCzBjLvIpsUqUcP5LcgyJKv+DFmhUVgS TCUqupFWzMXFmBHvQHId7kZ7lTSFS8x8zdaZaTWIZydFkfT46uVVZFiBxlfl FdenK8l0Kq/4Dl3J+3F5yfPoUjq9dzfkqnBMT8cWPu45uq+dvTuUN1zPNqqm tWk2SnuP5foyTBdvpvEk3r2dp/0Eln1SlLddgyrt9fujcvkZjlUuvzz5Ok/z hKRyWcC2qvUZ571hecNpONUN4ImNjV1YunEXhFLcm21sXA3TQgPlNMf6tH4y wL48ode0TdBkW9pgPukx26AqBJaMQSiDNilXcB+qqtb2WZ6BcslG8DRo0C1x G548BgLc0jikWt2MDo/bW3va4UyDXnXn6WimxaDRgNFXtO8mKNdiS5tlWiF4 FyQ1dGWYJjlSAJofaUK5PqIMnvdm8zyhVRMXRQbKZJb0tWme9RKYpQJrGsS9 FAYFN1jpxt0RP1BAZfRDVMgjwzujLLubT5EKJY/CnTwZUe1Q5/VkHE8m8D1M 8x6qYkFMGMF1eAmDvRomSj+Z0MV8OgVdDDZGUczjSQ/0Yj8tetl9kj/uULvw rSIxtI7U2NGSCfQS7QBgOxxsWp8KdeziOeiDIkiyKRAP5HlBcxCPiqzGEinK jJgmH6YnmS2SZAIdGwySHGexBwqrYClVWTXaZp5lsx0UOqVciUc8iHSCYqs/ j0dbSidA8oFywLVOZgYZWsiKM/gfxyZ7cpsL/psNlyYGhE2MhAUmIlaYJTz3 RB6osJ/0oL85MPC3BBTtIOnjsGGOePxYxWKYwnSLecBWwRK4j3tAfVw4SdxF RhFzAW3PR0i2RzSXpqMUZ0xT16m0FXsZ9PthJglfV3kZlMhRIN6nwJJ7vFLH KciBZGPjVxTYedafE/U3Ni4qAoNNiGsSTBhUGKPnmI557omFunlxGAE/nk5A 8SGjaaN0nNaoApWrXN6LJ8AFGuop7T6NtWYOdksPlKsGNe3A+p1pMNhk0k/6 tedgWopsnMxSVGmTBKjf52UwzuBZXI3QLWgrGbF0WFpcgzwbYwtYDxIVKYnt 4ff5JP06T7S75JF0abU613eEVmpyH0MjKscWSaJ9/w7WE8rV3UF6a//xx79r nfQWmcjG6r5/F1L3jz+2YKa+B1AIzMh8tgBzdBcY63by+y89MiF/+WPj/8Bn 49/qH+2Vn6XHNuhBGLLBd19djSaeM+nXxr+tufvqaspfUM32rvhsr6smCsP9 9+b7NdUoz2E1P6h38Fe2u/tvu6/8QMFMPvdD9iaj/9b25ulBKc8J2vyg/8SQ t8sh4ueIuKqg78odbk8+t66aH9qbs9MIh4ifPby8x98z7ewS7vx4VTX13vwo //rJ3tQ/ajV12ixV0zKXq3lvHorCy/xd3amqgeer3vwm57E2rUrzKxMOn99W BqU2oq35+dSdtdVkv8PnBJAzyBj4plZTv5OtVLMteW9dmxKRr+/NtsJ+wCet S8EmP0mbjB79oSxN2ZsLVUPWaLPmjnx0VVBsoqq6vjreWiHxU3eYNs9Jv9fd QemnPf9hxvyxUmy7ItN2VWzpxspTP7SzOZhTPY2kkmC733i1ojUAKnRNWz8k PR8lS/1YvfFSD7XlJb2+h6uVZK8o9gM9Umv6sLZL2xsbIMQB/EQJmlHowtDC +yztb6AsC7Q3yQSsg5Ek1WkXDRiwY6IEzZgNFGuBvHkZDxIw2ZbLgJSA+t8n YLOPkt1Ztns4GeRxabLD/ff1++Ir61XSvdqvqrZmUP37L29GWRe6RqYW2AvX BeAN7RLUcpynmbapKnShzrdAW298GIJZGy9DDkIcW0LzWw3Q/GiAzIsEbWrF EEGrguyftSaHsJnyBE2Ne7hJ1oxo7EVotIN2aW8I5jDeL+pWLyKxOrgZCUVF bSBCALMeDVEV8qWEteAh+Nln4Act0bUS6Ul79ZJtU+0SzOIR4CzEMJdgT26G 0ykMNX3Qwj1z2TwiOzDmWsXowe5P8AEy7nJtCN0eQePdRxgAW8GCDkDYRTIa gYX1668lp7UyMK+ngF2fwoTJuIuTUkJBgFW9IVBTEA+GNo6hw2DYTsBWfhbr fv9OLoM//tijARTQMZjL3hogqE5y3ENMiYRAJKLOyCKdDZEY7SuBMAhjAQgF GCSxDUFPqA/oQOY3zV43wduxNsbB5RL1lCMEs53oJgEfzk2FqMDWHmZ9RgrZ nAxqAJPTRPibFHYASofkOUIUjAiMSULLtZCtovTgLif0e8qrW6VAMQdCi2XR yx+ns+w2j6dAfjTNCaj2AWUKcIQd7SW5gCIMIHEm6cY0I9RJ+HwqpG4dahfZ PEfApLVqDW1yt7aoRRo6rVWoBv0gSCZsDNp4BAogZAabXTAhtr5TjkFgt7B6 ijAm4WKcd8HtTsMBkYAUreGgPeDQ58aqdkxQhak2itMxUoJnfgrYYnXWV/w3 GSKqbKYV5F591MIwhNnvwQpLi7GQVjBCqb4OFUIqiJKcKplwlsBMk+A/g0lA CAjoUAJHcomodWyeHR5u8Wq9RAbD/iWC16jzNclTlNy0LMdo9mmtyBJ9wGm3 5X1G/MiTCdRHaxeuHp7duzA0mJiHHVx05YQehichzQzV+9nUdSOw9CDYN73P NMaLiyKZFeU8sEBiiYnQ+yrJx+kkG2W3j9r3X2fVrz9oqBeM9PtqOR454lBA hLD0fjm+vrz6ZYf/1U5O6ftF+/z68KId4ffLg/DoqPwiS1wenF4fRdW36snW 6fFx+yTih+GqtnTpOLz5hd0Tv5yeXR2enoRHvzArq3OA3AcD7grfzhT0Euuz flL08rTLDN5snWmGDXz+34DRTcPwgdH5h2eQIlzAyuDGMvQe8E+YJFhLIGjj HCsBzgH5PwXBMipwerRimC0mGkithDkm7PdT4WWIcHHRj2KZxcfxXUIzJfkA p4PXFW+7sW9LKL0pXsjmBetXWQnIimYyyhY0/GLexcnf0W5x74wZBuTfbYod kU/sUGvUEjNJTWhqZ6MkLtATgms3I6YULRHbxdXIhAdoh+UHD5E7P3kEfZuT FAcWRo9aDxqChQVqIEYV2MEBgUJKWCebrGqFexgmoT6z0E3ckQvDHa2FfwEs 2NEOW+HpjgaLdKc0wuCbcPrtgI7H/6EcaHWeTjDn17SsGExPtNuqRNwOaU6u ThGFz1TLxtW6ag8i6OEBGle0asOQlidq04NS14sN1w3VUFOdmAcHh1f0uKQ2 y0reUcEtvhm575i7xjzdOInSiuwBI8MlNqeuRIX7tNWLNpNhertdMKru49Ec uSEW9hVWTgIKmCFH6wAXHJmHoNXGYJCOHkWpSodrMC/YQ6hlAsZcD2cJPbPE VWOumfTPcJjO0PL9448dZVlRt0te2qkNeskfV2oxohdQlUxrBXsgEth97ufS 7+2NH6o8BsxRzdAhOjpoGi7nKfs/f2inFy2YWO0gLoYATX5om6anAR2LLQIs 6i/8qfyi365dFf6PdbsGgfaXMdH/3nj29lKBNfehxO5zH/X5tY+/9FEq+FPP qzUs02rl81SBiowS9CaoH0PSyWjOSCPzUXKCsMCV60oVm4atzvfy56kCP/6K gagYUy4ziS+XEWIzT+K7Piw/RJGq/GFjhOUPrYopr4olU0SaKLzGe1mOWyHZ hJCBMHNwH1isazZ/JMaDRfzZ2tPhj0F/m3vp1N2L82m895nl1GHYBMsGREwf jBRhbt3znkSejRT7rGwI5EA0JwMBOz6JaRNl2QgF+TkCeUcYaFbw1hdqtWE6 xScnaZc3zrC7OBDxfE0WblZKzWH8SFuugB6FWx+siFwbQR3Uz6rtzXQv2dt5 icc2QVNsbWm/dIGi2aL4RalztsiIc0S36ttP6zlzE7TQFow67vFM1M3TPegB Q4flyUbtFoZs8YuJfwgeHh5w9m2bDVGoerXAY/D4qGMpx/3MVrHSxxp9pTVM w/n8sMd/nmILavHz4x7+eansCtSAQYEizASIEVZUOUYMKUFjkIlweSq287UT eDgHcHbCmgejHmCyy6AIxNnUTMoghLffxI5fSptCaPn1Yjb/yJyHuZGqmaA4 W7JlZAMxzR5AWGyI9tzzOBZADeuF7mpiIMi1e2y4wzywBidK6juarfvujuYZ vklUM0zT82iiME4jvxc2grpTJkxU6BA2sRmDXbk75R08uQbibgYziOSER9Dy JP4Ui4Tk2Y60TnoEvNCwRsLkgt8rjBRPkwfqmcSQFUfSEIixGMkCj1M0CTKw GK4qEjIw3ceV/4kxOAYwlCSrdkl58x89O/GMLFheogIxK8s0hO7tECGgDlo/ MMMvuCK0DkYFITdJ5CYZjjgr1qAbMuAEGS4tSFgUJNKKtC86SUBjPuojyOki XRi/saHPpINpASMMAXHJNrFY7mAW7iCvF/MxoF1+oJXepyMtFEhDlQxgaQv4 e82z334AquKEopA4Bm4fFcJvBXISTU6xRPA2O+9YdgAUuR2OkOQw5EVR2+Ke zGTQYJzvlpEDY6xc+PfYFZn0Mg4n2Fl6HCCpoAdeB4ZBXgVeGmYa6K5iX2gE 4dRc3komZfLIfovRLEWAAh1lTVWkKIskn6BNLKFNtmJ1kml8i7CbHDXFkLGm oMZeuSsxYWCuAUPi17sJmrdx5ftk1xBzrGDvWpxCuUQkqaqq8dHHqVhb0qOV TSULVKhNbsqXPiGcLwB6OLViCVUTIUIVUCqi+68bV1g1r/SUomZVV52MHBkn s5ichzVPGkwMDAt5OE5HjC1Vu2CYjYDrZW0re9txvhRtIobMwxFjLGfvG4b0 kFhhtyk1jsNSXDG1bfl6Z4o91aN0y75bhcx1kl5E4RlrfR+9aFAV+lRAAqMI Qs8fs0hFFhCd89mraVpxkojXENO/VwZS0M1hLO0hoHIhVW3JK7hAkEPn+eS5 oimO/Sx+lPgfVzCLNlqjMJwsWF6R3fljUZFE7AmUTVPL0/iRZ7wsJkhZCrKS wTc2mo+Kg4HWf56Q9538M7DycXJLPiAfRc3w08LqLj5Gw4V/4xzUEvToUZvM pSN6iUIYAgMylkmSxDC5vPaBRUDIIg6VnEa+0Hkxy8aIwlnXk/T8tRKX6O1X ZTkZXOiJFxAVFYucw8f9cmFvbKLPb+vpLa7t35/6PLN99kN7wjx6bjOt1lL2 ypaWcMxL8IU/P568s3Ei9doLDVVLdl8RkqvlyKJ+RcdfO0D57Xmwnq2idwUl 1qtcaWNNm9vVnNCm63Y1RdXv5fvi9wZWqe/xHxk9YSz9Npd+W+XvjSdae+Xv VxL21azzNO9sHGW9l/iGW3od7yDzkAH4ihpfPUj57QVfTya/7O3t/Rz7rLLT a9nnCXYi9hH8UgXfmEu/raXfgz38oz3NPq/szb8w+5AifrbgyqX1sjxbvrBm 1D+0h73n/zhytb6qzZVP3X/UnxS7ZAOoTqT2Qzye4m4TooJS73EcAu4Qv9L0 523tMsQZt821+QQUJ+jXrL+D+/zj+JE2B7t1zEMqlSFJtQtHYBGjNLUe2P3z MXvFOS64R/ABzGP4Vsg9TQx8TR4ABf07WB4AArMpbVsicpSHFSpzKSbwNyIU RiAYw04ZW5KtgBtwO2pIZt1sA6tjAKUq24ENin3pL6DG4kltk1oJ5U1r4SXC mzbi3UwJxMggFfXipriISyC6xWQNSwhVbReupWFMpIlzqn0BM4APgEEIZaX3 i11JDIWwxwV5A/a0AzDadrQuYN47wvCiPJnTM2mGiy1t7RcKG0j66NxK8z5t GGO0colvcP/h8myHbDTcyabYcqir6gjv/KIzTFK2YBCOI1M7UnukpETVIbJf kehPeiSlsbm5uosrvGUV1gfrVvGlUsg/jEVEiPRwu22yDsq/gNLZz6TQqkLF 67Bs3Rlb45I17MRuCGWKmXYCOnNDVeRHkQovwIF6duEAg6HLiCAKQEJ/5E6d GDmgfNxfXtdqwvE+QI9JL0UREyNMng9i6miOKOue3EUyvqefMLDgKa1WDwB1 jMSvfHO8x8TbVYmQX7SFVJNwtJEUPQKgSHurq4O2xcSymmYFk7vIRnOGLDgg WTW7vUrPE3c4VrpcgsCC2bc2WeTFZTopcfZl3AjM+IBiHbTBKL0dsvRAXp7x hiEgsQHUvMDTUYICKEiBTwZJzL2GoQufCe4MJpP7NM8mDP8IBaEw3u0mCKKg Cz0+YHGQLRLafyVoWAoWKaTxyAnQI8W9SEJRYqRQdpTeocsFnesJVNgD6MsR 88wG8ykgZBlMdHi1zJ+M5kvGK4MwFCxM01OK7k2EbVAfCuRJsqDt+wqaqpIZ 3YW3ecKhLjtaMuvtbQEFQBNRRznQQGgHEfP/nLdu1VVHO9nAA8N4WgiqF/OR OCVHpB6RuQHa6i5hbwjJNDqXIn0oxQzmYgJCpvT6F0lJfxxvySQFiIlwNFJK vRxARR4W6bStTvRJF3Xpvsaq2I9T+b2AJ6luJRrrVxk7uSZUB4NRYMGBpXAG DK3E3FGsRS3qEE/m4JYyeRhlvFbBUT6q223J3/x0LNgO+efhejF41C7ab3YN lvrcCwpIeD6WbF4JfeGvKVai18jTU+vmhVi18IXl3ubFxZaIqqui7C4urh6n iVytq6fbFrhyFrLYDjlDcKJIUpQuplLc0rZfnqO4ZXcmSxAZFFAL96qRfbNJ gaDfv3fxNlfBDIJloAruAQ4RVVDam4/iHMiejtFUoeWEAq1yvYHMuzgEBi1q 8WBKPNkWS2sKmiPOXxfpVYXMgXimc2McY6ZuySFZquAgMiS1z4r+3qzvO/Vx VWpP7uIR3SjyCdse3SdCiRPBmQh7WkQxobT7MRHruGZ7avVIGrmSCiHQxWxq x+ENdlkcoNU2VUXCG0m90bxQAsmiy/LZut+R1M68EAr/st3aYnNIrmV8GGdY TiMNUGl6ltUs0IpPahGBm812sVUPJ5R0tMByMvcMGRdDEYY4Z9SZsrkyQoWc tWQvkNjmSCQW9+RAB3t2NNgVYXGfW8DHE7I0amJfidz5zPMG3KnElvE+VxWk S95OGTGNO0F9kB99NiWxVdFZCgYTMWw8VlS4Oax8PDFFldbjROPRLUqOoYjt wkg6ZVeKxAwesy13DIVOhuU3mnPoFOiMAR7Cg190TJD0IvJ1gSdFxeSjl3un 2uRKaVHABO9KOagu6ComdDp8LIh2vWGMkCbJcZ+nV+xQP8i0w5NxpdxCgxHj oF/e9QKhSRsntf1xwgYiaDnFoOWa5GQWJZDDcc4KMz21JEv7g7omgwhKRccV A+2Ed1gGTe1jeCuyvJQhpQGqhiphV86uLlYLgSC7591OUi/EuXQIrx7LsAQx eNWJNbxTBXEtVV/bd6oiK4zPqmWPznsl6r4ce/kw1Xx+dXPWpkufpUvv9X+e 3UJPVJlXbcAoYdTy7CKuU8bztbO+FJV3cVjQicsl6c+6RRVJZQMF6uDeM7pK 3Wd6QlKRUOP9DGQ4JeyZDJVl3Uz7oDza+h0wW6RKVUmyVEioXzEQt7HF8XWl elYm/R7Pc8yLMpADn1y7gGU83uQ3UK33YHvFwnwn+ufJbiL3aw+AAaViWp61 Mso6T6YjhO7EN0sPcFQfyII+bsHh3qSQOGpNeKCbN2Flu5VFgJfHeLKdDhav aK3XyG9pONDRAQmZfytUTquCpFU/U47ntYWU5+MIoIGHGCI6ww2eySDNxzUw J3ibJkbqJZC7GR9/0VrN0wvmF8wuAgZq93GWiPDJVhQdiXuuoePmHw9QGn/l LlcV6bhIYaowQQJz3q8Yof0ALF3PmlFy2S5G3P6h9JDjNkRhrplzoHA/MC8K GtGTvtQqdExdyl7czq52vxZ4vHyXXDi7RYKOHqwRw2FmgLtvQSNgQBhZy/AT uE201E9vUwRJrJ+xR0BXnLWJ9OlkXZw7osVgjiik+wWEuURNVQvk6oIOgNFE 5q2iDmS2FegWjBSeS4HoJ3j2mxZCSeZhXMiwmRHWDCb4qF+QxmJ90M+I4ato buZOikEZpKPljCX/zvuMsRzzKLslThVj544zMuQqeRp/xWjRagKfnE/1sjqv YPqx46CfFrAyH4HR82lGJiJ0Z4c1QDXtFaHa8qhWlMa3E9zX7yGZhMQtVIVa HnV6Ux50Yr4VnNhB0oEti+HzU0a0VceZrn+IvUtxVftd+zs5mOk3L9LdGUiB QJvDpOzwvbS/q8a3B9oMqKjtoS2zaThbXKonZcKuujh3UUUEGvLLxj+kQ1pE M5ZLSbqjSTx9gKuodDHGGNcneqMRCAu+WCPJ5KInOdUvwT6645KcAlkA8PSB RvSQjJnEQW5sBCQHPi/f+czNsdgXC46QngjMqpnMFNlFI0LKoX3DSUTQGcP+ 1JLl80Qu6zEu5Rlb/qw1yKsAZgk5ztj9HRMWEu5zeGiYjKawHsm+Zf+6jLfg CtBTJldIGYJDPpv6oYrv32XGmtKG5fFWOnsuwi5AfNVKIMSRyCJmQ2EkHMQS HdWOo7HdViXqIIe1EotJi6ebPGa4cSAi1hXqLhuoGKcdqrxYTeHSndoUilXP AFWOEWMKlAdkrClWVLmsOMwMrDp1bQtnJSuRyrBk24mMmdpxEDYe4tmMxTbj Sw5s24M+FyLRBD8pbgjfnCC64PBBSl6+MqxoAFZLBQOAPR5ihEBjSj+jSqpy 3VDIIQd7apupMErAlkly6crQhCbJ1JqlhRbzhsGSVSwOFdLjHHLIJxCgTUMv myuvmXplFZeEIvdQoH3WdT3UwH620WZ92c6o5v81NknJERx1opivInYRmWT5 QJgw62lVL9sXQBLOwBS1hZGBiZnKRaU2IHwDKg4ufcvC0Y580iNTjEiNyWuo A2QFiXBjZFrA2lt72iXOiVodeXlTGJmyhMC4kvyknClU1/+OBNovOxeXRpRW riDgFN5BqZ0vJOYS527l+TbggrTPBymlVSlDNpO0PFqIUYwr7q1VU770bbEi fvkR4RWThr0nDHtxpIW2x1AKrh4qrfayeLWi8bzanDxyw4iHNyxxwnoznlGO quMepfXMMqk063tJiq56aqFee5YLX0UGsFzQkaK+VZu/PDddbq2mMoGSYsWj 1xHuj3Hz4QnEFRdPnTMV8/UZ41TFmpKWYb2GPBHBd7M1Zr42nzL0w/PKqNRW jjV3y46JZ3mZ/JfZ+8xdrzX4JS/+/xb//yMWfzmh/5omP+0OIW9rcmZG2eRW usFibZRMbkEhs74V3k9iLuor6y5BIdJDch/0OSxRkqQOJuRlQBPfCQvM4+Kf aNtqv/8PcUiEn9gp76Yw4XDz79v4axcAxm0+/Qff/p8UAC/u4tfaPVR48DTe Jt0H98rH8iTG6/ivel3uQAkvFpSoX1HLyl1e0YT8iUU2/tio+loCp7T/T8ZL fxM3Z7yvo4yU4Y/AS6a+BUBIDqusJpa10B2uQ9xAXqtVYeztWa5J1YiRVtXA hX/SuYRAg2Km4+xU1/O4n87BxhqMsni2QyklMZdALx7jZmdRFYQCWV6Vg4KL 28Kzd4cxoYvl4qCxRpS0mB54qvg/NlapXvabbgkS6Ht73k51NVjDQVWqYvUe NCFZoqwYYU9Vb0mPfsXXNTRrWkhWddbLmhTOWFOhcnfNdKusARVuTigBsk7h yGk8grnCrwVqZ6rA3tqo+KD+gPAs/pPzagSas7Wh0gAKQ7cMZ6Nagpq+Ua44 zdjgxaWZG+VK0qwNXjqavbG8VjRno7YkNLcC8Uv6UaJ48gGvQ/G0+UidXI6S FyH6ZGWh9QvP8nkkNaCH0ux+/045bfFcNYrgfsrpQMHw2bwih6rBKXzpu7nF h69I/ZRbsetPxbPFEffubjnpp2qboVSWIDHG9DOCgxU3r0hgUAMNPFawhmJM 3SFMkOQBnwdKPYLRgifSSAELt0LpwRA6j+wVPqnFVoQ4VAH6mkw7HAr5neWp KJmLRdQnDAqyFTkXDgcRFGVkmkyPQdUp1YTrhslSv0ISaACTIU27tXk8KXDv OOFQFzXTCVl/1ITsBBh7YCqwFsqmMSZOpINANKtieOTZp/wZ9UB8ggeIOMX5 7qg8FCKPw9TiutStGZmhg7HUkyFiOxzRiFt+peEqEnnIHQi8NC/mwEB0I5+P KOQJv5OlMUrjtEgo2QSnmdypYHs9//FSsNhSEuRWeEphZ7QRIyLNJGVFDlL1 uB2UbOGxNZFHEpMjw7zcJpwr8ldBT5oKGckhTj3QJYDuYXUgETR+eWpx+Qwm 7W5SBCbFM9TOcyxXw1v42PW/q6FYj5z24h+btbTO0CDldeZzy4Qk9hGtbgm3 njItOBYMHao3Ry6BWDNsJReCRJ+lPUaH+/a0zpyjVoU4KNgHlBZVF6tAhHHc T+qHSytuIBrvi7OKlLsXevGDCHGBt0TEb9XLNeHAZ/z0z3wwWUEt5Flb+v36 m08/BG3o2q5mKV29kAdP13RJO9kPf2oQYhw2tuH7vqxGObnbKvOOlzfbl29Q RgFegxW0WYUt2HuGLmIWMNk1neKuLQNuS9dxSJ7hG68bDz5EB3B3NcOxHB+v X0/KPD+rD3XSHHBrC724/PWSG6h11a73lFqB6l3sm+FanoVcIYJo8FDnSivq zToRVmkAigdECOfpVYiBihzWN18ppA4vGbf45Q8BluqrjPEBiOL3uL5KL1zl +1MicqUrCfMeI3rHWCx6goKyJAQvy2NqFfIvzurntysu2KwLNuEqrYL38MGJ Urc4qAtNizV2IROTUDdC4fBBDEneCAqsBJP2TrqEa/mUcTzAeNVJ/SisklfX TkhLuYdRLDgoxY0OX2RqJPRz8uFK6k1r6aClPK9dHZPO8jJhAtJbOrXVDhVK jxCwY+Yi1aSBRYMBFpxwa0+Z4ZrvFO03AfHENPPUrVKxHMCJDGiicVAQFHTn d33ryVt4uv3pu7jonr5LR+HhdmmSIifjIFU+rswDypaFcY44MGmRfn6i7o9b n+WeU5knTebzwuiqJOeGhstJwqS+eyYlBmcEEHY75bCQWQGS3pCd2GL65dwc yG2TE459u6TEF99/rdUBA6oSFyxlLgND6OmI+NJ1gvQCtroFNgIxUhsUjL3K EUDWz0oSC1wJfKBAprGG6SgfEkOswrZlILxMjR4D4Evgtgjv66IdHucyqxIS XQoJBgXCIy7iJ5ScJmpqiy3pwqJVsflEOoWt1XwKYrdE5iPSGpqrOUATSzMB ZOiar3kr19b82YBb9T/Gmj9rKtvY3v2TfzbUE2N6TWE8KKfJYHC/g5ZpuIoa /vNtyrZ+PPNvW/zbUf7VNJIPOw+/6/qzlRgvVkITC/UYz9ZjvlgPsgbUYzzf H+vFeoizsCKjni1WXRTLJ7GasKqbaiqOcpZKRbxWJbKVCfZ6qRdZumHgHtYk 35jwfD6UQuY245MWIjkZ4zlp+Sumt9bGwwEn1ZEKaQ/RviRVQ8oJ19YoGcyU bD71TBdlfo80l05UJQWHokZpaLjhCMo+RxVb5bdR1j4lrLH1z3LPrXZciQ40 UDC/zC1AMeEYtm5ze5t8rkDIApQbW9XQeAhjmZOGOkTESmh4P2GYElWXAaMC EgH5vRr4VXBsk93MLHtRQ1Ea3EdChdDp/8H7IJfv2ZE+IF/HQDG2oEVUApJv UkoT8vc36exg3q2Q2i30ct7Flzvt0wtwFrf0Dpz9p98wto9v80pn+7HXjx2j O+jFg15/4Btewxt4nmv2HNOz9DhuWG7DM3s+yG0glcbveNrRppzlEGwwdIYQ L0xwZ4HOxzAVRZae9FtSy1nySD4HcdCGDT0ZNiY2AdiGlitojZ28sXE4kJ7G MuhcxG4K5URbrgVl4kxnVbYDNU2CzCArE14Q1xWc60JVtKXD65ZTSNM2MJ9k 4QOUwvRQTWsZrEv9RY03L6QCA5YgnkIdXcxB8PRT3PQRfC1DLJiPhb9IxsZS 4AilYMmXmBV7Uipj3KJio79em9i94hNudHAA6lEgy472DGSB6TnFQG1i9ynH B/Qw9zJ59pQcnJKs5UrkoPtyEsvtxFlSyLepINkyuWaUFEwU5l/6HXgmhJPh VxlQqkQJSf9IFfvzM16Sldr+GjfJU3FOExb3OwKArImjoizAuI9a3VEq4Q2n ROibcqZVPwkPIP5z4FfEw0h7F1unXpUHjlYRZ1WojC2RGLO8tQI0qQQfxiuz 7SjROnQUTUWH4gxUlbZWcIuwgrllmWroiSgo6TCt+YLTQsZG4NGaIz44Q9XS +ZT6SxR3QLNcdZBeFB67SLq7UwzsjccZ2gno9C2epN1TaE4hkjLmepCeiqae qbiyTkSuNGqiEE7/0k8m/NJ8AG1QHa9T1gw5zuhpxW6tWn7x86PCpWzT/oyL 7AWXmXCG1Zs7AVkYicG82DeadlRssm/GUoHXJeN/qjZnqTZMUfMyyZ6qzV8h 7MupDp8ZqVWv7bkMh6+gm1svsPraqc3rJzJ9rKutUS/whjeBWiI/5aVQI5tv WpfLda6rzXupb7VXYr1Um18v8MwbtDB/w3yUPFebqddrO0tHwL+v+qyrzagX kPmc/2RtZr1AJN87p/0NKDbpDfOs3BmR74PYjPAtEGtrW+K3dW+REC+ReE3f 7HqBk4Tet0WBWbLWM7b2oNbLs63na3Oeri0S0SRVbdFLtS2tBRpdIl7JFuGO 2poeRtTHdbUtrYUWgNG+dklRa33qYSclRf+KOS3ViEyhqWoS1fapqw3SJnh+ bE4yYd32HxjRp0rGy78tRX0uPUG+6dq58QvVcEFsQvY6Wb49fslH9ZZlTAl4 Jc6Lj6dgr/Nr9UASDuQRHH5xSflOD0zRV2ag5H3uubJNK+NxRIK2Llqh3Aew TjEEtEdnBdXj0JgSRdJjU9oT+XwyUY6IUpChkoYiecBxcHhPibnFGwMJamCK en4Ryx7Y4vze0j/+UKPAU7a38V2heBB2j6CQOFcpXkGzw4fZ8MqZ6DwJTFZb SuSRPHzPRx5l4kWKkhSlcHMc1QEmKRFVYrBYl971mExH2aN4miLFS3qMARvO c2FXwON0MmpPPaipJMUH87R29FN2Xc0W8+RwCsxOp8bcCj1NrkglNciM+1eV Q1CohM4unaJWrPAtjmmsjq+KcMeS3YryzRj0ZtNCfZlxIRLKMGtX+XrqWSmZ SjPlMGT12o50Xdi9YH5Cfvz2HHQKSI4aPZa2nNgA5Q4meMgNuXPNeeryiMQD blok/XV9xu7eIzGp3bl4NwnFzvEOzZnMI4GNVK96bZ+diZfnuP5yPselJJSC 7arzDALUyyyBcp29NkXkmsBhThb5RKJIPFANVOdcGFwSRYcyhywbSqGgJBFR 8/3y2QLhbSuPIVcLpFqEvImtZLSAcUv58pqMFoIbpTwQwSmp8koBAtb9uZCL lC8kHWZZn1+lCd2kjvM7TJHyMJPinDVucI3xfHTZb3r/7UwWJrmcT8SZXPm2 hB0lFHo58EQE4/BrXiixDp3dQQ4mv5ZYYdqh2E4TQdgs1crT7OIYPhrmxIoY UTMfYcQSciEGq6BHZ5plAwpems1izFXEWafEjiTweSZCELrZLagCfk1smXer 6h1NIaW8ZG8PSD4ZMs9RNCyauGZxxlKpUzg1qQLyjmQzzs9CpyfzBIUPBp3h kdWSzLVZUPlKUrwKJq/O3bNMmA2xzjJyCYg7SflAUJlpk+mxwydWH6vf6XjK r/WRnpfeiJcyZQR6DyWG6Rd+E7tIuF3PcAU1TL4k5UvCMPHOHLRdlaZVpAbL s3FKM5jQW5U52684Waq8oXdfzR4P47tE94Xyel1643Jyy1RRk8agOC3lGIeK FCm+ipeEaVc6AfkdWksChjbE+I1dUoz8hPiokvaLF8dVihmZh4+T7Wj9Ko9+ FRSMv8R7L4b43gtQVjyC8l1Fm2oyCKf2gpStHZislNQpaatfFvHojlPbz/Ik WTkIUnpMyPmuKkIkD7szZW4r5SC+ohaFWw8fR0ZgpzgnVKuOkYhBKm8m4/NZ o1HFJhxhXuvdppKWCKUjyFflBLx4B1Uq3/5Lq4oi3Ms3xYkzeMrR5srXBAW2 5BEMfkFR/EjCVQh7SlDByTpkoF7tcLPGArfHW9NlOIB60F4cxIB2d9RT16un OWonACtPXPnyGzrewblXcIcl7oMZJtrjU07qzA1EmOSyAcNEV2RySfRah8rc xKxM+EX02gLk0SyZ1Hvo7i33cfVVZ+U7hQphH2JEuwj1IhaVeTFKYbpXhhH+ Tfr43sHMtVFS45sfNzjtO4ai0svg6bhKXDyOx/j+RH6ZXP2FC8r8j1G6dDkU MR6JjSfa5i4XjhJDsD7dQrFXe+FjKa2XxA8h5DINgdQ+0unIveRsjvMJZ+/a EcFr+a0QrfFS1jLpUseR4KkYmSEtHYjIgGSCOeI1fIs275ahnJ3PpNqYZosk 35JCSRgv+OJ1fuGjmtGF1N0kK1e5dCED8X8rdyB7tUzj3UTJ2g5jQuGJfZjD YhuJJnL5WjRKSlaQnBHp3jDZEeovOj7HJrE4jtiLKVXNTMO9ptk697jYgOE9 n51SNAhXsDL/8p3r6nqpXqUorQGxKYU7M+qryIGY3XSiLB4Y0C9f+MWMRPNf JAGwsvIVeypyeU2ul9MpZtAfjR6lJ59IVlSHddBhgueQEY2Jg74l1OV9XZm2 ji2kWLuU83XJwez4eiUymYosm5TJnFACorqntJ2YOeRwVktdAygHDT6yeJgf rq+OkfmoU5eXUmCPuR41tajG3lHubcFiIBZMW6HvsrtVL28xrwYhDjoAo4U9 TPYPK5e9r+RCiCd3tGwvZ3PEbi0867QZfkQ/BkZ/g+W6ox0dtXhjt5l1teOs uMtA1n/TNg+ursgpga8twHR2VK7a9E4o9xZhUvlWBmUHKKW8iOSUIA4pH6DM f2l3zpIAoHNfHgue9BVAOKsUiASPPU6gKdlLNYRqu/1ADPR7Y2A8kkWGKXzC TctOilE7f1uKniowY2mZ9Yp2N2mr+bMaXp3PJzKKYEeaK5TYkZhhUTNuT6oc WWoIEGUeVV5GwxF2cBFfECxeaUfDQf0vIBaBGvEilDSTPgX5dkxOYoWhBNhV MQLc4977XL5uF1FHEvfLUjKiC/fG1OPX8kyWPIzPlQl9kmd3iWKvsFHGaVbp lY3iVJlyYAEBHklmccKM0sLSRr04tI12HPapDBfZ4bia8tU+suBMnHBfLmlA 0UWSV5u/ardZV8rJhyd5P3TptaQkLL9TfAv6/MrjYf/99OLwzeGJ5iiJihLK Jr0akKZSfaOx14UbMRTw4QFjr7HnwN8xXIOC8F2DSqnRTYrUuV1Mp8fmp/Fp K1wcR+Hiw3nnzfHhYfP8S6vpx2FEhcLbdgv+N47D6zfh42zUi8L8+PJu8XZx E70/P+dCUSt8hBoe4P9vn8afRlgb/G+cfLg2j9+0H6jQyVXv4dPV3cPNVTM9 +RYmnYX+eHIV6sfRHTx8bVKh4y+f4tqNK6gBrh039Yc338JPVKh5e/K+GYJK vLu4vHwfzq7vOs2j6/bs+Orm28m3mxnXFIVfy06Hx8Pw7fjc6DaPel/fhJ9m 52+p0Dvj6MB4OzqbeZ3c2P7S9NvR/teT5pmXtPczfbGgQpdfwjNs8uDiuBkO vHbzKozC84P946j3JjSu+1Sofd5u7i/OZ8et+QFQrBlG+9thGHY+jlvD9w/u BZ96OkredMyh3j9ofjtNvfveuDM8Gr+3bz4Yi+6b6zkVujH9WdXxk2Z4dH32 ZXjYtPLF14/nyZQK5f7++6i5PRzOFvMPnw4Xxun1XXse5R03at3d9hpUyFmk /Y+Tj7GzP48G/XdHjf4nzxqfHYzNq4FlRvdUqOuF39oL7/eNrXpYaJ7vkjBS IkORf2sqXnA4v0JNPNTrZjmaX0P5Lhw6YAzrnA4cX0ThVbjGCq7M47IibL16 vyEfKjN0OodXxp9vlt3i92a/O+T3SPxiDQaepsPnF5GT5TdL90zdsE341+g4 oa5bOvyG/+Fvy7FE8Jqju7plNl2ngfeblmH68G8DrzqObusWF2uZUMqCIpZB f1sufhz6Tn+oGFTrwEXX0l3DwkYalgG/ffgbHnNNi6fJ0o220dAjqBFrsOF/ n2rHR03LdUIe+2oRoyoClfBatAyjCT/8qst6yzBt2zFt39HNyOGFZhu2YUb4 P9TiWhb0zYXvOGqoC+nAIxXEgH8NXfd9X4+cpm43G2ZoeLrrRjYX882mY7Ya ke37dqfZaBluM2q0vZbRsW290wk9lhO63enAYK1OaNktS7exqQ731IiAJiIU 0eh0oOMwUuiOgb+gX42ymFErhp02m14DpxIK61an08aJ1x2nTcVcPTSchtH2 jVBvNjzXaLhew4Y/esOyQrNjdqhYw3RhWsw2jBbKuBG013Id+G25sKiQJNyo W5HEhuaajt7x2gYwUdRutszQ4VnQG6EfdqJO5AD1O0ArWJdm2/F9mNfIbsNk 8Jyabb3dNBohcJRvQoea7Ybu+ZHTbjhR2G50mlTMsxpRZHrNdhS5jVYEfWo1 /KZrQ/0dV293XB5CCxgRiNj5TU0dpCxLuZY58m8QDBJdD5zASVw9iIFGgZH4 RhDr3YYWifWqLlFcyPWlDuZ6banLVY7ZPRgBry5rlg9yWddSkxCL4OndMof/ e3wRIZ45tbRN/cGsXhJzSQdBMSazm+SB5tB9y1EKlBgxlNkpA60dmcBBflno ENOqw+OtEzzhyewzQKoQ+wBZkCpIFKRJ1SmExIAsa28awKiGJuGTQAunuab5 UGHguIHpwhfT0d4cX608EFI0XvWA8dQDl3NKLyB6irbuLki+3XCXLJJdfbmg itAxnWxQa1q5+Qxx5EdcF0/twlPBShnAV6sX8eP7ga8HfSfo6oHdDRomMFrg 6YHrBn070P3A7AaOGfQa+POpGuxB0G0EPSNwu0G/ESQefh/Yga0Hg0EQe0Ff xzIDY30NCTJ7eecjsOW9BaYa7YvQ+Te1sLjdjAugECKQWY4vCSsCrYevmANY vtJGKwyuLq7b66qR0xGOxAlGkVr5mdoAxoQcnRjwOu0EKNBwnbZhnYa0TkGY BSjNdlYev744DGTgG6w41UBkY+aldVEVEFFPsuauE+iDwEsCwwygX/0k6PYC Mw6cfqA3gtgP4kHQH+Bc673AGNBEu9XjfSicBA7wg4m5PmG6Eycwbawt0YOk GxhQiR70TCwAFVrdIGlUj+te4PdBVAUNJ+jHeGvQDTwraPSDvhl4UBi+uEGj hx1zLeQoX+FJ16a+DQIgYQJ/D4KeHlhWYFgwqFVhmeCbLH9aWCrCTMR3qYdp +MDHko3f2+u/xrKP+eUy8ACgu0lh7A378a6h12ZXDkKGDES1ozyKqaZAE+rQ GmjyNxaNIk3a91+xuScxSvwzGAWL+3CrATdtGLwDfyeETgxAKS6/xGUZpzgK TmkOAaccEE75Bjjlaw2ndAb/yTjlKvzG6OJqVMcpX8JveO24aT8AUeM6TtEZ p1y2L9bglKtw8e5L2GneHuefPobR4Xl0Gjdt0744j13j5oSN9EnsJR9mjcHR xbXz5uy4GLRn9iKzw/M34Zl7csw1tbNFhMO90K8QnzTD60W4AFjyLbSwK1To 4KJNIOboKsyHD+FteB7u79+G75ofbt437j5eU6G3i/HtcNjP+gcXi9637P7I eju8uXRGgF5mvTcPLLSOxif33auq4+fn4fB4enp5Or49vnt7wzbaYLvpT65u 48X1l3f2TRsIMOt9O76bHER3p9niIyuux0k3Pjpx9aubxB9+PXG3W2+tyxOv m7+9S6zhlEcHwup+GN29BZziAe8kxCsmIF4XeMkiXkoI6Zrrech/NQ/d/DQP 3VwBD325eTj58J5pcxK9vzuJDq3jaDSEAss8ZIiZv1jmIQOvvYKH7l7ioVbr eN+cz87jo8X1kFGzfnF62xh8s60waV59sS77Iyf/YB/dXp33OqO/hocub06N qJ8zD32wsxoPmcO7V/BQM/ZGnx4Hs4eDt18jNmvf397bF7Pt3vH1uOfF54tk Zl9/6p9aj+enTX/+lS3p4uh9eNmLP7U+fGnpk3FycXf7/mKYfkuMpBg8pozb Li6ubfswbKtYF0XbEtZF0YkCcb8SgmsRLzz6F0FepRMrkNdegryyd09B3ngZ 8loEed065HU6/4KQF2tGCOM/DXnNqghWIiEvgEmAdyrktSrIazP6tO21kNeo QO8KwkPQ22q7ntG23LYBkDlsNx2BjCO33XCbAMTcZgMQb9N27LYNyKzVNDrQ RlvQLbQ8xLCe/hToFVj2JdBbK/YE6A3FEFzXcNpt24lsmEc/1FdBLxUzOy+B 3hUOYdBrGhYwCWDZ0PX0ls/FfNdyGtCNRuRHlmeELcP2WmHb8AwdKd90WgxS Wy3fbMCE+XobKOF07FbYcKPQBFzbtO3IYw5pRp4bWo2w45lmo2F7Ucdohi3f N9pR2wjtlsduDC9sdzwb6vJroFddmWsNuVh3AqRSkCQ2GJRAp8CP9Rdgb1nr T+HeupT4i4Gv7+B9Z/CvBXyNQAfT2n898DWfemAN8AX5VwJf418X+fYAhngA EgLLDQCBGoB0YoQ5gPD1fuACkHERQDV8RLVra2h0Ec507cABrGQTqIGfBuJc sx8kgFziwPIQi+lPIF8A2v8PIN9QrlUUaUFEazXU/yuhLzC0BbjUIuwa47wC xPX1wHcDywkaA0SwAEQBoMJ8wDT3jMD2qsd7MXKAB/NkBzbwATBBD+ey5wcw FqMXWH6gJ0EMM+qgXwPKN1TkHAcmwVpgBbsfeI2g20doDeUbcTDwAlg+jQa2 CPgWKo+hb371OLAgPAu9snuBB1A5RgDs2dSov0ZkPoV9XxCZS+CX5F76n28d OWusIzbb/mPmkfdXmkdo+0jzCFQrGkYumkk2/GvD32AWoXlTFXvaPHLgb/t5 80gU+ZPmkf+T5pFnWlYnQrtId70mKn0q5vhgs1ih3o46rY4XtfSGZ9htK4rM huu03aYjPNtmW7cjvaE7fuO/zDwyXeiWDfqjaTpu2/SeNI9cz7X/hHnkhB2o uGE22lHLBhOLwaXechxXb4K54kYdv2UZtu+3OmDLWHojBKOGcYzrRBZYk75u IVO2w6bX1JuOrdt+y/XBzHGZvC0TCOn7bcyGazjQSa9pNZpOI2w1OqbXbNiO WB6W19Y9XbeXzaP0RfMIqASSA8gECsqEpZ+Y3sv2Ufqn7KP0P80+8jyyj7y/ zD4CyqAQRBnYJ+s6rkyQn7GPHLAIfso+Wv/AE/bR4b++fQSqyLKCQT+IQbE5 ge6iE5cVp+MHfQNds7GObt1Bb30NoPn6PXQVg2a1wc4iTzAoTidBk8rporYD xWyTf3ptDUBUvzJv/79sH6FICyJarE1crCDVnjeQYNX9hQaSA3aIiaZtA2Yg wWmxG9Ancug7ZPJ20VCxXTRRfDB4YMYUEwWugFEb27gxACYNmitg74KRYdHG j4/oACZ5AJZ0HHQ93EwClikft3Wsreei2aP7aJ71TOIFP/ATbBR4CuwW+GLA s2A1AXcoHAH2EphwpodtgWUDJcGKA8YB61m31wjN5wyk54Tmmu2B8hAeZikl ofo3ClX+j3rZ2S/ag79t8rf7exQUvOfRO8+MFe/ow9sl72j7Br2jnajVfHDr 3tHrP+UdPf5ys/j04ZzF0fG3nnnz5dA4GV8/nq54R9vCwx41l7yj7W947Thk X6fwjpZO87dH6XZ/tJ1+iJzZoDO6sou3ISvB7X7e++B5bw6+PpxFp1PHPR1a 21+PG1Dr4gQ6z07GC/2CHJ4tffHO7p0fhu3wbN8OW7fXV63WBUfdjO/u3xTZ zcf44ELvHRy7R49+9ulNe/7p43DY/djkHM+fLp0vXVNfNM9vonfm+wXYQKEe dXv9yW2rsd9ku2c/PvryaXyUJpn+qdOKuv39d4cP4eO29dF8N7uyOTpplvXf P1wcn4V3J24GltZt3OueDK7eeFN/Mm33uOPJzTApRuaX5vnvGMPzmpmnYHie +WwRhuHNYfv6vF25cS+OD9++GceXXsyqLMxuOx8O75rbs4b5aZHP/HFPFg6b 751brul9L7mLW9b4U/S+aM8es5vm2Ajv8uticD2+3mY7bvHh/qN7fKCfn21n env/wb7ynq7pvuWPjbe38/uPs8YHM7MXD2fzcXzFpt7hmXV1fmINzs9Mbzg9 nFwejorLxVfvunXyZWzGHJTVmPav7sdm++vg9O35ydm71uj+4tPY/np16oDJ +v6GCqXnbz7aZ58m020Y3aOM3Mo6n4Yf5xf98wnbW3F9V2Z5Q4Z90OquzOOT MWCDe+vr9vjoomk9xs7V+MuNt221vvWz6NOVf8G++u2P0xNnGKWh+/bx8aH5 9v46WTwcfTs7GV59PJ96HLnVjhrGx7DtmbPj8cwaNO1v3W8fTs6Pmu/Tt+F5 PmSv3LgXN/Y/TRR+Hkezcyt+fD9/d3j4TXCjazSz++ZlZ3LRdqPZ/tmXXtPu nJ7135ofx7MuC4l586S5+PCxqun9uJM4HaPVe5sdfmFWaeXp2xYwcvjh6vTg bDw6ONLN43eX0+LgPk2vviVU6OuieeC/27/Iv9lG6yZ98A/ib+Hhafjp1Ov0 Bte8ao+3Pxwdvf2UxecfmgeT4+7V+YKY0Do9Mj9tf1vI0a1l28dL+37yaZBR odHtdvfjw6fr7aPW+elgElud+7Pm0C2uFt++JskXLtTfz1b2MXAL4/Z00PO+ XKW8/m+Oxlenp4+dT9n1g/nl9HQxaxpfJl+v3+Zu9ybmPh1nZ/mFdTx696b5 5kPx/pvx+PHk6/X1Rdb6etNfFMx0iWvc953UvXn7dRLyyi0VDWY/X46+q97a jWJ7Xz3OUtuSEM/+xzG30okVzO0R5r6e9PJk8VSWhudBN6BuAN2txhLotv+z QLdJOxIMtgnYuiYBZyxsWt7zoNuAR6C+50B3WQTgqYTwMo5uaTfBN9tmx4+E 3dn2fFfv+E1YRq5jdwDsAfLz4X4YtZxmqyPC8Ix22LI7eqsdNvy21/YajU4Y WlaTOkA4mAlSBsg9hYOpmATDBk6GDbAytJstsBsrHMzSswyQewoHM2ItA+SW cXCkW27UanDfGp5utrFTBohes41TBZRohF5k+IZt6hErxgbiV69l6y2MdmtE Xth0rLbuN6FjjtNypEOgo5tgZQER7MhqeUbYMJoW7iW4HdPvuI2QhwCA3mr4 nue0wSqOcLuhhoOV1fKkRYdECpBKgR/bgFDArnsBBstafwoF1xbuXw2CbQLB 9l8JgtHQRTsXzVy0cv8MCMbgG/1nQPATD0gQ/C+LddHRmwTmAD3EPgWw+S4G U/kARAaB4aKHf0CwxtfX12D5wcDHwCeAVoBsewMEzEaCvl57gN5oAEYAd6Dm xHtiN6ERDOKfxLp/MUhVlhJInABFzn8lSO3ruBcDBGwATvUC3URH+ACwo0Fu CBO3VFw3cOGLiTDU6weG6ke3YURBv4u+dgC7HqBMGynfBcDXR/e/FyMqtRLE oF0X/fSOAlJ7DgebYbs2ee5jC30TVg+hbdxAz73F7n8X6/cHgauCVBshNeBg mGVo2kmCromhd7RpsCrRnsOoz0m0FS++qLCbp/2XDIo1R22fNiX4xUc6vqSF NVyg/d3eAQNBN5Z9tstq6jfxciMzEK+awY9TcRLW0Qmjdsd1G3rYjvDfemx4 WRSDxOvx4csh7mVRjHV/Psy9LIrx7lWo+2pYulsVVZtutkDTQiu+Z7ahWrjg NN2wLGp5LbAz2m2kQ8cx9U4UWbYeRVHHhu/NludW/hTTbNgemBYtu6mHzZaj owEEOtT1I6ig4Vhl0SbY+54d+h3L86E2qxXqodOMDFDPbTO0W+3Ke2U7euu3 naco7jfaOlI6bLTbKxQPFYovBycsx1dUDbgvxViURduWGmfxaoq3O1E77ISu GRl6o9Hyw7Zj+QrFoSWYZb0Jas7TI5jyyHbAOAPrImq7ht42q2GBodQwoVu6 7Tcju9HUgfStVsdyDTtq2GCTlEXNjqFb7Q4YM7phtcDQs0wYHTQPRABTynIq XQoc13ya4sDbBlIaiNZ5luIr+x1LWzbVDHsvbdtUfWmqWzfLSxbnuJocNRLF g9kJm8CbOtDKAqPfBR6rZGyr44eO0WpGaLCHwJdNvdGELvtAqXbYVJau3ejY YScywo7VtkBdeR7whA1jBEvUA15w7aoDHR3mvINhSFbb8Zpmy3fBpPV1xzOM dsMyqmHBgJ7h8ajVxiXaaINh/izFl0VWZfWzwV+t1Gcsfzb6q1pr1v8yxXGO Fb5RJltvN6JWx7TstumjaEGCK+vfNBw/NGww0z243tSbthGBrGiHQFNcG9Ui 89wmzJhntZt2o2GZDuAF3XadsOU0rKhhOq2qaOjbjgFLzAx96C1MtddohpHb aYAx3gxdXVlkYUM3fqNf/9j4Y0WRod75U4pM1ULCNP+/MGWYNTDGAAA=[rfced] Regarding artwork and sourcecode elements: Per Adam's response to the Intake form: "The only sourcecode in this document is a series of CDDL blocks." A) FYI - We updated two artwork elements to sourcecode with the type set to "cddl": Figures 4 and 5. B) We also updated Figure 9 through 21 to sourcecode, but we have left the type empty (i.e., type="empty"). Please let us know if the type should be set or if you prefer they be left empty. See the list of known types available here: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types --> <!-- [rfced] We have the following questions regarding terminology: a) Throughout the text, the following terminology appears to be capitalized inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Apex vs apex b) Please consider whether "Authoritative Name Servers" should be lowercase. Lowercase is far more common in RFCs. The majority of uppercase instances are where the phrase is part of a document or section title. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: master Section 5.1.1 (master file): Note that the data has internal subfields but these do not appear in the master file representation; only a single logical base64 string will appear. Section 5.2.1 (master file): Note that the data has internal subfields but these do not appear in the master file representation; only a single logical base64 string will appear. --> </rfc>