rfc9886.original.xml   rfc9886.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.24 (Ruby 3.2. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
3) --> -ietf-drip-registries-33" number="9886" category="std" consensus="true" tocInclu
<?rfc comments="yes"?> de="true" sortRefs="true" symRefs="true" version="3" xml:lang="en" updates="" ob
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft soletes="" submissionType="IETF">
-ietf-drip-registries-33" category="std" consensus="true" tocInclude="true" sort
Refs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.27.0 -->
<front> <front>
<title abbrev="DET in DNS">DRIP Entity Tags in the Domain Name System</title <title abbrev="DET in DNS">DRIP Entity Tags (DETs) in the Domain Name System
> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-drip-registries-33"/> <seriesInfo name="RFC" value="9886"/>
<author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" ro le="editor"> <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" ro le="editor">
<organization>AX Enterprize, LLC</organization> <organization>AX Enterprize, LLC</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville</city> <city>Yorkville</city>
<region>NY</region> <region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>adam.wiethuechter@axenterprize.com</email> <email>adam.wiethuechter@axenterprize.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Reid" fullname="Jim Reid"> <author initials="J." surname="Reid" fullname="Jim Reid">
<organization>RTFM llp</organization> <organization>RTFM llp</organization>
<address> <address>
<postal> <postal>
<street>St Andrews House</street> <street>St Andrews House</street>
<city>382 Hillington Road, Glasgow Scotland</city> <city>382 Hillington Road, Glasgow Scotland</city>
<code>G51 4BL</code> <code>G51 4BL</code>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>jim@rfc1035.com</email> <email>jim@rfc1035.com</email>
</address> </address>
</author> </author>
<date year="2025" month="August" day="19"/> <date year="2025" month="December"/>
<area>Internet</area> <area>INT</area>
<workgroup>drip Working Group</workgroup> <workgroup>drip</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 81?>
<t>This document defines the Domain Name System (DNS) functionality of a Drone R <!-- [rfced] Please insert any keywords (beyond those that appear in
emote Identification Protocol (DRIP) Identity Management Entity (DIME). It is bu the title) for use on https://www.rfc-editor.org/search. -->
ilt around DRIP Entity Tags (DETs) to standardize a hierarchical registry struct
ure and associated processes to facilitate trustable and scalable registration a <keyword>example</keyword>
nd lookup of information related to Unmanned Aircraft Systems (UAS). The registr
y system supports issuance, discovery, and verification of DETs, enabling secure <abstract>
identification and association of UAS and their operators. It also defines the <t>This document defines the Domain Name System (DNS) functionality of a Drone R
interactions between different classes of registries (root, organizational, and emote Identification Protocol (DRIP) Identity Management Entity (DIME). It is bu
individual) and their respective roles in maintaining the integrity of the regis ilt around DRIP Entity Tags (DETs) to standardize a hierarchical registry struct
tration data. This architecture enables decentralized, federated operation while ure and associated processes to facilitate trustable and scalable registration a
supporting privacy, traceability, and regulatory compliance requirements in the nd lookup of information related to Unmanned Aircraft Systems (UAS). The registr
context of UAS Remote ID and other services.</t> y 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 regis
tration data. This architecture enables decentralized, federated operation while
supporting privacy, traceability, and regulatory compliance requirements in the
context of UAS Remote Identification and other services.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 85?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Registries are fundamental to Unmanned Aircraft System (UAS) Remote Ide ntification (RID). Only very limited operational information can be sent via Bro adcast RID, but extended information is sometimes needed. The most essential ele ment of information from RID is the UAS ID, the unique key for lookup of extende d information in relevant registries (see <xref target="rfc9434-fig4"/>; Figure 4 of <xref target="RFC9434"/>).</t> <t>Registries are fundamental to Unmanned Aircraft System (UAS) Remote Ide ntification (RID). Only very limited operational information can be sent via Bro adcast RID, but extended information is sometimes needed. The most essential ele ment of information from RID is the UAS ID, the unique key for lookup of extende d information in relevant registries (see <xref target="rfc9434-fig4"/>, which i s the same as Figure 4 of <xref target="RFC9434"/>).</t>
<figure anchor="rfc9434-fig4"> <figure anchor="rfc9434-fig4">
<name>Global UAS RID Usage Scenario (Figure 4 of RFC9434)</name> <name>Global UAS RID Usage Scenario (Figure 4 of RFC 9434)</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
*************** *************** *************** ***************
* UAS1 * * UAS2 * * UAS1 * * UAS2 *
* * * * * * * *
* +--------+ * DAA/V2V * +--------+ * * +--------+ * DAA/V2V * +--------+ *
* | UA o--*----------------------------------------*--o UA | * * | UA o--*----------------------------------------*--o UA | *
* +--o--o--+ * * +--o--o--+ * * +--o--o--+ * * +--o--o--+ *
* | | * +------+ Lookups +------+ * | | * * | | * +------+ Lookups +------+ * | | *
* | | * | GPOD o------. .------o PSOD | * | | * * | | * | GPOD o------. .------o PSOD | * | | *
* | | * +------+ | | +------+ * | | * * | | * +------+ | | +------+ * | | *
skipping to change at line 92 skipping to change at line 93
| Registry | | | Registry | | Registry | | | Registry |
+----------+ | +----------+ +----------+ | +----------+
+--o--+ +--o--+
| DNS | | DNS |
+-----+ +-----+
DAA: Detect And Avoid DAA: Detect And Avoid
GPOD: General Public Observer Device GPOD: General Public Observer Device
PSOD: Public Safety Observer Device PSOD: Public Safety Observer Device
V2I: Vehicle-to-Infrastructure V2I: Vehicle-to-Infrastructure
V2V: Vehicle-to-Vehicle V2V: Vehicle-to-Vehicle]]></artwork>
]]></artwork>
</figure> </figure>
<t>When a DRIP Entity Tag (DET) <xref target="RFC9374"/> is used as the UA
S ID in RID, extended information can be retrieved from a DRIP Identity Manageme <t>When a DRIP Entity Tag (DET) <xref target="RFC9374"/> is used as the UA
nt Entity (DIME), which manages registration of and associated lookups from DETs S ID in RID, extended information can be retrieved from a DRIP Identity Manageme
. In this document it is assumed the DIME is a function of UAS Service Suppliers nt Entity (DIME), which manages registration of and associated lookups from DETs
(USS) (Appendix A.2 of <xref target="RFC9434"/>) but a DIME can be independent . In this document it is assumed the DIME is a function of UAS Service Suppliers
or handled by another entity as well.</t> (USS) (<xref section="A.2" target="RFC9434"/>), but a DIME can be independent o
r handled by another entity as well.</t>
<section anchor="general-concept"> <section anchor="general-concept">
<name>General Concept</name> <name>General Concept</name>
<t>DRIP Entity Tags (DETs) embed a hierarchy scheme which is mapped onto
the Domain Name System (DNS) <xref target="STD13"/>. DIMEs enforce registration <t>DRIP Entity Tags (DETs) embed a hierarchy scheme that is mapped onto
and information access of data associated with a DET while also providing the t the Domain Name System (DNS) <xref target="STD13"/>. DIMEs enforce registration
rust inherited from being a member of the hierarchy. Other identifiers and their and information access of data associated with a DET while also providing the tr
methods are out of scope for this document.</t> ust inherited from being a member of the hierarchy. Other identifiers and their
<t>Authoritative Name Servers of the DNS provide the public information methods are out of scope for this document.</t>
such as the cryptographic keys, endorsements and certificates of DETs and pointe <!-- [rfced] Why is "Authentication" capitalized? Does it perhaps refer to Auth
rs to private information resources. Cryptographic (public) keys are used to aut entication Messages or an authentication approach?
henticate anything signed by a DET, such as in the Authentication defined in <xr
ef target="RFC9575"/> for Broadcast RID. Endorsements and certificates are used Original:
to endorse the claim of being part of the hierarchy.</t> 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 of DETs, and point
ers to private information resources. Cryptographic (public) keys are used to au
thenticate anything signed by a DET, such as in the Authentication defined in <x
ref 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 Informa tion Registries to store and protect Personally Identifiable Information (PII).< /t> <t>This document does not specify AAA mechanisms used by Private Informa tion Registries to store and protect Personally Identifiable Information (PII).< /t>
</section> </section>
<section anchor="scope"> <section anchor="scope">
<name>Scope</name> <name>Scope</name>
<t>The scope of this document is the DNS registration of DETs with the D <!-- [rfced] We are having trouble parsing this sentence. Is the scope a) DNS r
NS delegation of the reverse domain of IPv6 Prefix, assigned by IANA for DETs <t egistration of DETs with the DNS delegation of the reverse domain of the IPv6 pr
t>2001:30::/28</tt> and RRsets used to handle DETs.</t> efix and b) RRsets used to handle DETs? Also, is "of IPv6 Prefix" correct - per
haps 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 D
NS delegation of the reverse domain of the IPv6 prefix, assigned by IANA for DET
s <tt>2001:30::/28</tt> and RRsets used to handle DETs.</t>
</section> </section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<section anchor="required-terminology"> <section anchor="required-terminology">
<name>Required Terminology</name> <name>Required Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " <t>
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
n this document are to be interpreted as described in BCP 14 <xref target="RFC21 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
19"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, ",
as shown here.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="additional-definitions"> <section anchor="additional-definitions">
<name>Additional Definitions</name> <name>Additional Definitions</name>
<t>This document makes use of the terms and abbreviations from previous <t>This document makes use of the terms and abbreviations from previous
DRIP documents. Below are subsets, grouped by original document, of terms used t DRIP documents. Below are subsets, grouped by original document, of terms used t
his document. Please see those documents for additional context, definitions and his document. Please see those documents for additional context, definitions, an
any further referenced material.</t> d any further referenced material.</t>
<t>From <xref section="2.2" sectionFormat="of" target="RFC9153"/> this d <t>From <xref section="2.2" sectionFormat="of" target="RFC9153"/>, this
ocument uses: AAA, CAA, GCS, ICAO, PII, Observer, Operator, UA, UAS, USS, and UT document uses: AAA, CAA, GCS, ICAO, PII, Observer, Operator, UA, UAS, USS, and U
M.</t> TM.</t>
<t>From <xref section="2" sectionFormat="of" target="RFC9434"/> this doc <t>From <xref section="2" sectionFormat="of" target="RFC9434"/>, this do
ument uses: Certificate, DIME, and Endorsement.</t> cument uses: Certificate, DIME, and Endorsement.</t>
<t>From <xref section="2" sectionFormat="of" target="RFC9374"/> this doc <t>From <xref section="2" sectionFormat="of" target="RFC9374"/>, this do
ument uses: HDA, HID, and RAA.</t> cument uses: HDA, HID, and RAA.</t>
</section> </section>
</section> </section>
<section anchor="det-hierarchy-in-dns"> <section anchor="det-hierarchy-in-dns">
<name>DET Hierarchy in DNS</name> <name>DET Hierarchy in DNS</name>
<t><xref target="RFC9374"/> defines the HHIT and further specifies an inst <!-- [rfced] "HHIT/DET" is a bit confusing, and it is not used elsehwere in this
ance of them used for UAS RID called DETs. The HHIT/DET is a 128-bit value that document or any RFCs. Because DETs are a specific instance of HHIT, may we ref
is as an IPv6 address intended primarily as an identifier rather than locator. I er to just DET? Note that we deleted "as" from "is as an IPv6 address" in the s
ts format is in <xref target="hhit-fig"/>, shown here for reference, and further uggested text. Please review and let us know how this text may be clarified.
information is in <xref target="RFC9374"/>.</t>
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 the Hierarchical Host Identity Tags (H
HIT) 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. The format is shown in <xref target="hhit-fig"/
> and further information is in <xref target="RFC9374"/>.</t>
<figure anchor="hhit-fig"> <figure anchor="hhit-fig">
<name>DRIP Entity Tag Breakdown</name> <name>DRIP Entity Tag Breakdown</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
+-------------+--------------+---------------+-------------+ +-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash | | IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28 bits) | (28 bits) | (8 bits) | (64 bits) | | (28 bits) | (28 bits) | (8 bits) | (64 bits) |
+-------------+--------------+---------------+-------------+ +-------------+--------------+---------------+-------------+
/ \ / \
/ \ / \
/ \-----------------------------\ / \-----------------------------\
/ \ / \
/ \ / \
+--------------------------------+-----------------------+ +--------------------------------+-----------------------+
| Registered Assigning Authority | HHIT Domain Authority | | Registered Assigning Authority | HHIT Domain Authority |
| (14 bits) | (14 bits) | | (14 bits) | (14 bits) |
+--------------------------------+-----------------------+ +--------------------------------+-----------------------+]]></artwork>
]]></artwork>
</figure> </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><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 (Section 2.5 of <xref target="STD88"/>), the uppe r level of hierarchy (i.e., Registered Assigning Authority (RAA)) "borrows" the upper two bits of their respective HHIT Domain Authority (HDA) space for DNS del egation. As such the IPv6 prefix of RAAs are <tt>2001:3x:xxx0::/44</tt> and HDAs are <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>Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address (Section <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 b its of their respective HHIT Domain Authority (HDA) space for DNS delegation. As such, the IPv6 prefix of RAAs is <tt>2001:3x:xxx0::/44</tt> and HDAs is <tt>200 1: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 Num eric 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>This document preallocates a subset of RAAs based on the ISO 3166-1 Num eric 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, 8192 and 12288 are reserved for operational <t>The HDA values of 0, 4096, 8192, and 12288 are reserved for operational
use of an RAA (a by-product of the above mentioned borrowing of bits), specifica use of an RAA (a by-product of the above mentioned borrowing of bits), in parti
lly when to register with the apex and endorse delegations of HDAs in their name cular to specify when to register with the apex and endorse delegations of HDAs
space.</t> in their namespace.</t>
<t>The administration, management and policy for the operation of a DIME a <t>The administration, management, and policy for the operation of a DIME
t any level in the hierarchy (Apex, RAA or HDA) is out of scope for this documen at any level in the hierarchy (Apex, RAA or HDA) is out of scope for this docume
t. For RAAs or DETs allocated on a per-country basis, these considerations shoul nt. For RAAs or DETs allocated on a per-country basis, these considerations shou
d be be determined by the appropriate national authorities, presumably the Civil ld be determined by the appropriate national authorities, presumably the Civil A
Aviation Authority (CAA).</t> viation Authority (CAA).</t>
<section anchor="use-of-existing-dns-models"> <section anchor="use-of-existing-dns-models">
<name>Use of Existing DNS Models</name> <name>Use of Existing DNS Models</name>
<t>DRIP relies on the DNS and as such roughly follows the registrant-reg istrar-registry model. In the UAS ecosystem, the registrant would be the end use r who owns/controls the Unmanned Aircraft. They are ultimately responsible for t he DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Regi strars typically provide optional additional services such as DNS hosting.</t> <t>DRIP relies on the DNS and as such roughly follows the registrant-reg istrar-registry model. In the UAS ecosystem, the registrant would be the end use r who owns/controls the Unmanned Aircraft. They are ultimately responsible for t he DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Regi strars 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 th e relevant registrar. The registry provides DNS service for the zone apex which contains delegation information for domain names. Registries generally provide s ervices such RDAP <xref target="STD95"/> or equivalent to publish metadata about the registered domain names and their registrants and registrars.</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 th e relevant registrar. The registry provides DNS service for the zone apex, which contains delegation information for domain names. Registries generally provide services such as the Registration Data Access Protocol (RDAP) <xref target="STD9 5"/> or equivalent to publish metadata about the registered domain names and the ir 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 f rom a registrar who pays for services provided by the registry.</t> <t>Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: the registrant buys services f rom 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 re gistry can have an arbitrary number of registrars who compete with each other on price, service and customer support.</t> <t>By definition, there can only be one registry for a domain name. A re gistry can have an arbitrary number of registrars who compete with each other on price, service, and customer support.</t>
<section anchor="dns-model-considerations-for-dimes"> <section anchor="dns-model-considerations-for-dimes">
<name>DNS Model Considerations for DIMEs</name> <name>DNS Model Considerations for DIMEs</name>
<figure anchor="dns-model-fig"> <figure anchor="dns-model-fig">
<name>Example DRIP DNS Model</name> <name>Example DRIP DNS Model</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
Apex Apex
Registry/Registrar Registry/Registrar
(IANA) (IANA)
+=========================+ +=========================+
| 3.0.0.1.0.0.2.ip6.arpa. | | 3.0.0.1.0.0.2.ip6.arpa. |
skipping to change at line 192 skipping to change at line 237
| | | | | | | |
+=====o====+ +====o=====+ +====o=====+ +=====o====+ +=====o====+ +====o=====+ +====o=====+ +=====o====+
| 1.0.0. | | 2.0.0. | | 3.0.0. | | f.f.f. | | 1.0.0. | | 2.0.0. | | 3.0.0. | | f.f.f. |
+====o=====+ +=====o====+ +====o=====+ +====o=====+ +====o=====+ +=====o====+ +====o=====+ +====o=====+
| |
---------------------------------------|------------------------ ---------------------------------------|------------------------
Local | Local |
Registrants | Registrants |
+=====================o================+ +=====================o================+
| x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. | | x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. |
+======================================+ +======================================+]]></artwork>
]]></artwork>
</figure> </figure>
<t>While the registrant-registrar-registry model is mature and well un <t>While the registrant-registrar-registry model is mature and well un
derstood, it may not be appropriate for DRIP registrations in some circumstances derstood, it may not be appropriate for DRIP registrations in some circumstances
. It could add costs and complexity; developing policies and contracts as outlin . It could add costs and complexity to develop policies and contracts as outline
ed above. On the other hand, registries and registrars offer customer service/su d above. On the other hand, registries and registrars offer customer service and
pport and can provide the supporting infrastructure for reliable DNS and RDAP se support and can provide the supporting infrastructure for reliable DNS and RDAP
rvice.</t> service.</t>
<t>Another approach could be to handle DRIP registrations in a compara <t>Another approach could be to handle DRIP registrations in a compara
ble way to how IP address space gets provisioned. Here, blocks of addresses get ble 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 addre delegated to a "trusted" third party, typically an ISP, who then issues IP addre
sses to its customers. For DRIP, blocks of IP addresses could be delegated from sses 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 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 Aviati by <xref target="RFC9374"/>) to an entity chosen by the appropriate Civil Aviati
on Authority (CAA). This third party would be responsible for the corresponding on Authority (CAA). This third party would be responsible for the corresponding
DNS and RDAP infrastructure for these IP address blocks. They would also provisi DNS and RDAP infrastructure for these IP address blocks. They would also provisi
on the Hierarchical Host Identity Tag (HHIT, <xref target="RFC9374"/>) records f on the HHIT records <xref target="RFC9374"/> for these IP addresses. In principl
or these IP addresses. In principle a manufacturer or vendor of UAS devices coul e, a manufacturer or vendor of UAS devices could provide that role. This is show
d provide that role. This is shown as an example in <xref target="dns-model-fig" n as an example in <xref target="dns-model-fig"/>.</t>
/>.</t> <t>Dynamic DRIP registration is another possible solution, for example
<t>Dynamic DRIP registration is another possible solution, for example when the operator of a UAS device registers its corresponding HHIT record and o
when the operator of a UAS device registers its corresponding HHIT record and o ther resources before a flight and deletes them afterwards. This may be feasible
ther resources before a flight and deletes them afterwards. This may be feasible in controlled environments with well-behaved actors. However, this approach may
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 i
not scale since each device is likely to need credentials for updating the IT i nfrastructure that provisions the DNS.</t>
nfrastructure which provisions the DNS.</t> <t>Registration policies (pricing, renewals, registrar, and registrant
<t>Registration policies (pricing, renewals, registrar and registrant agreements, etc.) will need to be developed. These considerations should be det
agreements, etc.) will need to be developed. These considerations should be dete ermined by the CAA, perhaps in consultation with local stakeholders to assess th
rmined by the CAA, perhaps in consultation with local stakeholders to assess the e cost-benefits of these approaches (and others). All of these are out of scope
cost-benefits of these approaches (and others). All of these are out of scope f for this document. The specifics for the UAS RID use case are detailed in the re
or this document. The specifics for the UAS RID use case are detailed in the res st of document.</t>
t of document.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="dns"> <section anchor="dns">
<name>Public Information Registry</name> <name>Public Information Registry</name>
<t>Per <xref target="RFC9434"/> all information classified as public is st <t>Per <xref target="RFC9434"/>, all information classified as public is s
ored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from tored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from
<xref target="RFC9153"/>.</t> <xref target="RFC9153"/>.</t>
<t>Authoritative Name Servers use domain names as identifiers and data is <t>Authoritative Name Servers use domain names as identifiers and data is
stored in Resource Records (RR) with associated RRTypes. This document defines t stored in Resource Records (RRs) with associated RRTypes. This document defines
wo new RRTypes, one for HHIT metadata (HHIT, <xref target="hhit-rr"/>) and anoth two new RRTypes, one for HHIT metadata (HHIT, <xref target="hhit-rr"/>) and anot
er for UAS Broadcast RID information (BRID, <xref target="bcast-rr"/>). The form her for UAS Broadcast RID information (BRID, <xref target="bcast-rr"/>). The for
er RRType is particularly important as it contains a URI (as part of the certifi mer RRType is particularly important as it contains a URI (as part of the certif
cate) that points to Private Information resources.</t> icate) that points to Private Information resources.</t>
<t>DETs, being IPv6 addresses, are to be under <tt>ip6.arpa.</tt> (nibble <t>DETs, being IPv6 addresses, are to be under <tt>ip6.arpa.</tt> (nibble
reversed per Section 2.5 of <xref target="STD88"/>) and MUST resolve to an HHIT reversed per Section <xref section="2.5" sectionFormat="bare" target="RFC3596"/>
RRType. Depending on local circumstances or additional use cases other RRTypes M of RFC 3596 <xref target="STD88"/>) and <bcp14>MUST</bcp14> resolve to an HHIT
AY be present (for example the inclusion of the DS RRTypes or equivalent when us RRType. Depending on local circumstances or additional use cases, other RRTypes
ing DNSSEC). For UAS RID the BRID RRType MUST be present to provide the Broadcas <bcp14>MAY</bcp14> be present (for example the inclusion of the DS RRTypes or eq
t Endorsements (BEs) defined in <xref section="3.1.2.1" sectionFormat="of" targe uivalent when using DNSSEC). For UAS RID, the BRID RRType <bcp14>MUST</bcp14> be
t="RFC9575"/>.</t> present to provide the Broadcast Endorsements (BEs) defined in <xref section="3
<t>DNSSEC MUST be used for apex entities (those which use a self-signed <t .1.2.1" sectionFormat="of" target="RFC9575"/>.</t>
t>Canonical Registration Certificate</tt>) and is RECOMMENDED for other entities <t>DNSSEC <bcp14>MUST</bcp14> be used for apex entities (those which use a
. When a DIME decides to use DNSSEC they SHOULD define a framework for cryptogra self-signed <tt>Canonical Registration Certificate</tt>) and is <bcp14>RECOMMEN
phic algorithms and key management <xref target="RFC6841"/>. This may be influen DED</bcp14> for other entities. When a DIME decides to use DNSSEC, they <bcp14>S
ced by frequency of updates, size of the zone, and policies.</t> HOULD</bcp14> define a framework for cryptographic algorithms and key management
<xref target="RFC6841"/>. This may be influenced by the frequency of updates, s
ize 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>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 defin <t>A DET IPv6 address gets mapped into domain names using the scheme defin
ed in Section 2.5 of <xref target="STD88"/>. However DNS lookups of these names ed in Section <xref section="2.5" sectionFormat="bare" target="RFC3596"/> of RFC
query for HHIT and/or BRID resource records rather than the PTR resource records 3596 <xref target="STD88"/>. However, DNS lookups of these names query for HHIT
conventionally used in reverse lookups of IP addresses. For example, the HHIT r and/or BRID resource records rather than the PTR resource records conventionall
esource record for the DET <tt>2001:30::1</tt> would be returned from a DNS look y used in reverse lookups of IP addresses. For example, the HHIT resource record
up 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. for the DET <tt>2001:30::1</tt> would be returned from a DNS lookup for the HHI
3.0.0.1.0.0.2.ip6.arpa.</tt>.</t> T 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.
<t>The HHIT RRType provides the public key for signature verification and ip6.arpa.</tt>.</t>
URIs via the certificate. The BRID RRType provides static Broadcast RID informat <t>The HHIT RRType provides the public key for signature verification and
ion such as the Broadcast Endorsements sent following <xref target="RFC9575"/>.< URIs via the certificate. The BRID RRType provides static Broadcast RID informat
/t> ion such as the Broadcast Endorsements sent as described in <xref target="RFC957
5"/>.</t>
</section> </section>
<section anchor="resource-records"> <section anchor="resource-records">
<name>Resource Records</name> <name>Resource Records</name>
<section anchor="hhit-rr"> <section anchor="hhit-rr">
<name>HHIT Resource Record</name> <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 v arious bits of HHIT-specific information that isn't available in the pre-existin g HIP RRType. The HHIT RRType does not replace the HIP RRType. The primary advan tage of the HHIT RRType over the existing RRType is the mandatory inclusion of t he <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 HHIT Resource Record (HHIT, RRType 67) is a metadata record for v arious bits of HHIT-specific information that isn't available in the pre-existin g HIP RRType. The HHIT RRType does not replace the HIP RRType. The primary advan tage of the HHIT RRType over the existing RRType is the mandatory inclusion of t he <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 data MUST be encoded in CBOR <xref target="RFC8949"/> bytes. The CDDL <xref target="RFC8610"/> of the data is provided in <xref target="hhit-wire -cddl"/>.</t> <t>The data <bcp14>MUST</bcp14> be encoded in the Concise Binary Object Representation (CBOR) <xref target="RFC8949"/> bytes. The Concise Data Definitio n Language (CDDL) <xref target="RFC8610"/> of the data is provided in <xref targ et="hhit-wire-cddl"/>.</t>
<section anchor="hhit-rr-text"> <section anchor="hhit-rr-text">
<name>Text Representation</name> <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 substring s 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 sin gle logical base64 string will appear.</t> <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 substring s 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 sin gle logical base64 string will appear.</t>
<section anchor="hhit-rr-presentation"> <section anchor="hhit-rr-presentation">
<name>Presentation Representation</name> <name>Presentation Representation</name>
<t>The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of <xref target="RFC8610" />.</t> <t>The data <bcp14>MAY</bcp14>, for display purposes only, be repres ented using the Extended Diagnostic Notation as defined in <xref section="G" tar get="RFC8610"/>.</t>
</section> </section>
</section> </section>
<section anchor="hhit-rr-fields"> <section anchor="hhit-rr-fields">
<name>Field Descriptions</name> <name>Field Descriptions</name>
<figure anchor="hhit-wire-cddl"> <figure anchor="hhit-wire-cddl">
<name>HHIT Wire Format CDDL</name> <name>HHIT Wire Format CDDL</name>
<artwork><![CDATA[ <sourcecode type="cddl"><![CDATA[
hhit-rr = [ hhit-rr = [
hhit-entity-type: uint, hhit-entity-type: uint,
hid-abbreviation: tstr .size(15), hid-abbreviation: tstr .size(15),
canonical-registration-cert: bstr canonical-registration-cert: bstr
] ]]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>All fields of the HHIT RRType MUST be included to be properly forme d.</t> <t>All fields of the HHIT RRType <bcp14>MUST</bcp14> be included to be properly formed.</t>
<dl> <dl>
<dt>HHIT Entity Type:</dt> <dt>HHIT Entity Type:</dt>
<dd> <dd>
<t>The <tt>HHIT Entity Type</tt> field is a number with values def ined 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 the HHITs role in the ecosystem like described in <xref target="drip-dki"/>. This field p rovides such context. This field MAY provide a signal of additional information and/or different handling of the data beyond what is defined in this document.</ t> <t>The <tt>HHIT Entity Type</tt> field is a number with values def ined 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 the role of the HHITs in the ecosystem, like that described in <xref target="I-D.ietf-dri p-dki"/>. This field provides such context. This field <bcp14>MAY</bcp14> provid e a signal of additional information and/or different handling of the data beyon d what is defined in this document.</t>
</dd> </dd>
<dt>HID Abbreviation:</dt> <dt>HID Abbreviation:</dt>
<dd> <dd>
<t>The <tt>HID Abbreviation</tt> field is a string that provides a n abbreviation to the HID structure of a DET for display devices. The convention for such abbreviations is a matter of local policy. Absent of such a policy, th is field MUST be filled with the four character hexadecimal representations of t he RAA and HDA (in that order) with a separator character such as a space. For e xample, a DET with an RAA value of 10 and HDA value of 20 would be abbreviated a s: <tt>000A 0014</tt>.</t> <t>The <tt>HID Abbreviation</tt> field is a string that provides a n 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 su ch a policy, this field <bcp14>MUST</bcp14> be filled with the four character he xadecimal representations of the RAA and HDA (in that order) with a separator ch aracter, such as a 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> </dd>
<dt>Canonical Registration Certificate:</dt> <dt>Canonical Registration Certificate:</dt>
<dd> <dd>
<t>The <tt>Canonical Registration Certificate</tt> field is for a certificate endorsing registration of the DET. It MUST be encoded as X.509 DER < xref target="RFC5280"/>. This certificate MAY 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 <xref target="drip-dki"/>, and is out of scope for this do cument. This certificate is part of chain of certificates that can be used to va lidate inclusion in the heirarchy.</t> <t>The <tt>Canonical Registration Certificate</tt> field is for a certificate-endorsing registration of the DET. It <bcp14>MUST</bcp14> be encoded as X.509 DER <xref target="RFC5280"/>. This certificate <bcp14>MAY</bcp14> be s elf-signed when the entity is acting as a root of trust (i.e., an apex). Such se lf-signed behavior is defined by policy, such as in <xref target="I-D.ietf-drip- dki"/>, and is out of scope for this document. This certificate is part of a cha in of certificates that can be used to validate inclusion in the hierarchy.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="bcast-rr"> <section anchor="bcast-rr">
<name>UAS Broadcast RID Resource Record</name> <name>UAS Broadcast RID Resource Record</name>
<t>The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format t <!-- [rfced] Is the public information static or is the UAS BRID static?
o 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 Original:
for cross validation. The primary function for DRIP is the inclusion of one or The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format
more Broadcast Endorsements as defined in <xref target="RFC9575"/> in the <tt>au to hold public information typically sent over UAS Broadcast RID that
th</tt> field. These Endorsements are generated by the registrar upon successful is static.
registration and broadcast by the entity.</t> -->
<t>The data MUST be encoded in CBOR <xref target="RFC8949"/> bytes. The <t>The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format t
CDDL <xref target="RFC8610"/> of the data is provided in <xref target="bcast-wir o hold public information typically sent over UAS Broadcast RID that is static.
e-cddl"/>.</t> It can act as a data source if information is not received over Broadcast RID or
for cross validation. The primary function for DRIP is to include of one or mor
e Broadcast Endorsements as defined in <xref target="RFC9575"/> in the <tt>auth<
/tt> field. These Endorsements are generated by the registrar upon successful re
gistration and broadcast by the entity.</t>
<t>The data <bcp14>MUST</bcp14> be encoded in CBOR <xref target="RFC8949
"/> bytes. The CDDL <xref target="RFC8610"/> of the data is provided in <xref ta
rget="bcast-wire-cddl"/>.</t>
<section anchor="bcast-rr-text"> <section anchor="bcast-rr-text">
<name>Text Representation</name> <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 substring s 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 sin gle logical base64 string will appear.</t> <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 substring s 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 sin gle logical base64 string will appear.</t>
<section anchor="bcast-rr-presentation"> <section anchor="bcast-rr-presentation">
<name>Presentation Representation</name> <name>Presentation Representation</name>
<t>The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of <xref target="RFC8610" />. All byte strings longer than a length of 20 SHOULD be displayed as base64 wh en possible.</t> <t>The data <bcp14>MAY</bcp14>, for display purposes only, be repres ented using the Extended Diagnostic Notation as defined in <xref section="G" tar get="RFC8610"/>. All byte strings longer than a length of 20 <bcp14>SHOULD</bcp1 4> be displayed as base64 when possible.</t>
</section> </section>
</section> </section>
<section anchor="bcast-rr-fields"> <section anchor="bcast-rr-fields">
<name>Field Descriptions</name> <name>Field Descriptions</name>
<figure anchor="bcast-wire-cddl"> <figure anchor="bcast-wire-cddl">
<name>BRID Wire Format CDDL</name> <name>BRID Wire Format CDDL</name>
<artwork><![CDATA[ <sourcecode type="cddl"><![CDATA[
bcast-rr = { bcast-rr = {
uas_type => nibble-field, uas_type => nibble-field,
uas_ids => [+ uas-id-grp], uas_ids => [+ uas-id-grp],
? auth => [+ auth-grp], ? auth => [+ auth-grp],
? self_id => self-grp, ? self_id => self-grp,
? area => area-grp, ? area => area-grp,
? classification => classification-grp, ? classification => classification-grp,
? operator_id => operator-grp ? operator_id => operator-grp
} }
uas-id-grp = [ uas-id-grp = [
skipping to change at line 317 skipping to change at line 375
] ]
uas-id-types = (none: 0, serial: 1, session_id: 4) uas-id-types = (none: 0, serial: 1, session_id: 4)
auth-types = (none: 0, specific_method: 5) auth-types = (none: 0, specific_method: 5)
nibble-field = 0..15 nibble-field = 0..15
uas_type = 0 uas_type = 0
uas_ids = 1 uas_ids = 1
auth = 2 auth = 2
self_id = 3 self_id = 3
area = 4 area = 4
classification = 5 classification = 5
operator_id = 6 operator_id = 6]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>The field names and their general typing are borrowed from the ASTM <xref target="F3411"/> data dictionary (Table 1 and Table 2). See that document for additional context and background information on aviation application-speci fic interpretation of the field semantics. The explicitly enumerated values incl uded 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 field s, such as UAS Type are transported and authenticated by DRIP but are regarded a s opaque user data to DRIP.</t> <t>The field names and their general typing are taken from the ASTM da ta dictionary (Tables 1 and 2) <xref target="F3411"/>. See that document for add itional context and background information on aviation application-specific inte rpretation 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 UAS Type, are transported and authenticated by DRIP but are regarded as opaqu e user data to DRIP.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="det-prefix-delegation"> <section anchor="det-prefix-delegation">
<name>DET Prefix Delegation</name> <name>DET Prefix Delegation</name>
<t>The reverse domain for the DET Prefix, i.e., <tt>3.0.0.1.0.0.2.ip6.ar <!-- [rfced] You provided this response to our question about whether there is a
pa.</tt>, is managed by the IANA following the usual IANA rules. IANA will liais ny text that should be handled cautiously:
e, as needed, with the International Civil Aviation Organization (ICAO) to verif
y the authenticity of delegations to CAAs (see <xref target="iso-range"/>).</t> <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., 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.ar
pa.</tt>, is managed by IANA. IANA will liaise, as needed, with the Internationa
l Civil Aviation Organization (ICAO) to verify the authenticity of delegations t
o CAAs (see <xref target="iso-range"/>).</t>
</section> </section>
<section anchor="iana-drip-registry"> <section anchor="iana-drip-registry">
<name>IANA DRIP Registry</name> <name>IANA DRIP Registry</name>
<section anchor="iana-raa"> <section anchor="iana-raa">
<name>DRIP RAA Allocations</name> <name>DRIP RAA Allocations</name>
<t>This document requests a new registry for RAA Allocations under the
<eref target="https://www.iana.org/assignments/drip">DRIP registry group</eref> <t>IANA has created the registry for RAA Allocations under the <eref t
to be managed by IANA.</t> arget="https://www.iana.org/assignments/drip" brackets="angle">"Drone Remote ID
Protocol" registry group</eref>.</t>
<dl> <dl>
<dt>RAA Allocations:</dt> <dt>RAA Allocations:</dt>
<dd> <dd>
<t>a 14-bit value used to represent RAAs. Future additions to this registry are to be made based on the following range/policy table:</t> <t>a 14-bit value used to represent RAAs. Future additions to this registry are to be made based on the following range and policy table:</t>
</dd> </dd>
</dl> </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 "I
SO 3166-1 Countries"). We believe this is intentional, but please review and le
t 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"> <table anchor="raa-ranges">
<name>RAA Ranges</name> <name>RAA Ranges</name>
<thead> <thead>
<tr> <tr>
<th align="left">RAA Range</th> <th align="left">RAA Range</th>
<th align="left">Allocation</th> <th align="left">Allocation</th>
<th align="left">Policy</th> <th align="left">Policy</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0 - 3</td> <td align="left">0 - 3</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left">N/A</td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">4 - 3999</td> <td align="left">4 - 3999</td>
<td align="left">ISO 3166-1 Countries</td> <td align="left">ISO 3166-1 Countries</td>
<td align="left">IESG Approval (<xref section="4.10" sectionForm at="of" target="RFC8126"/>), <xref target="iso-range"/></td> <td align="left">IESG Approval (<xref section="4.10" sectionForm at="of" target="RFC8126"/>), <xref target="iso-range"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">4000 - 8191</td> <td align="left">4000 - 8191</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left">N/A</td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">8192 - 15359</td> <td align="left">8192 - 15359</td>
<td align="left">Unassigned</td> <td align="left">Unassigned</td>
<td align="left">First Come First Served (<xref section="4.4" se ctionFormat="of" target="RFC8126"/>)</td> <td align="left">First Come First Served (<xref section="4.4" se ctionFormat="of" target="RFC8126"/>)</td>
</tr> </tr>
<tr> <tr>
<td align="left">15360 - 16383</td> <td align="left">15360 - 16383</td>
<td align="left">Private Use</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> <td align="left">Private Use (<xref section="4.1" sectionFormat= "of" target="RFC8126"/>), <xref target="experimental-range"/></td>
skipping to change at line 389 skipping to change at line 472
<name>RAA Allocation Fields</name> <name>RAA Allocation Fields</name>
<dl> <dl>
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>
<t>The RAA value delegated for this entry.</t> <t>The RAA value delegated for this entry.</t>
</dd> </dd>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>Name of the delegated RAA. For the ISO 3166-1 Countries (<xre f target="iso-range"/>), this should be the name of the country.</t> <t>Name of the delegated RAA. For the ISO 3166-1 Countries (<xre f target="iso-range"/>), this should be the name of the country.</t>
</dd> </dd>
<!-- [rfced] To match the column header in the IANA registry, should "Policy Ref
erence" be "Reference" here? If this change is acceptable, note that RAA Regist
ration 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> <dt>Policy Reference:</dt>
<dd> <dd>
<t>A publicly accessible link to the requirements for prospectiv e HDA operators to register under this RAA. This field is OPTIONAL.</t> <t>A publicly accessible link to the requirements for prospectiv e HDA operators to register under this RAA. This field is <bcp14>OPTIONAL</bcp14 >.</t>
</dd> </dd>
<dt>Contact:</dt> <dt>Contact:</dt>
<dd> <dd>
<t>Contact details of the administrator of this RAA that prospec tive HDAs operators can make informational queries to.</t> <t>Contact details of the administrator of this RAA that prospec tive HDA operators can make informational queries to.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="raa-registration-form"> <section anchor="raa-registration-form">
<name>RAA Registration Form</name> <name>RAA Registration Form</name>
<figure anchor="raa-form"> <figure anchor="raa-form">
<name>RAA Delegation Request Form</name> <name>RAA Delegation Request Form</name>
<artwork><![CDATA[ <artwork><![CDATA[
Value: Value:
Name: Name:
Policy Reference: Policy Reference:
Contact: Contact:
NS RRType Content (HDA=0): NS RRType Content (HDA=0):
NS RRType Content (HDA=4096): NS RRType Content (HDA=4096):
NS RRType Content (HDA=8192): NS RRType Content (HDA=8192):
NS RRType Content (HDA=12288): NS RRType Content (HDA=12288):]]></artwork>
]]></artwork>
</figure> </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 t arget="nibble-split"/> for technical details.</t> <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 t arget="nibble-split"/> for technical details.</t>
</section> </section>
<section anchor="nibble-split"> <section anchor="nibble-split">
<name>Handling Nibble Split</name> <name>Handling Nibble Split</name>
<t>To support DNS delegation in <tt>3.0.0.1.0.0.2.ip6.arpa.</tt> a s ingle RAA is given 4 delegations by borrowing the upper two bits of HDA space (s ee <xref target="raa-borrowing"/> for an example). This enables a clean nibble b oundary in DNS to delegate from (i.e., the prefix <tt>2001:3x:xxx0::/44</tt>). T hese HDAs (0, 4096, 8192 and 12288) are reserved for the RAA.</t> <t>To support DNS delegation in <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"> <figure anchor="raa-borrowing">
<name>Example Bit Borrowing of RAA=16376</name> <name>Example Bit Borrowing of RAA=16376</name>
<artwork align="center"><![CDATA[ <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 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 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 | x | RAA=16376 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | 0 | 0 | 0 | E | F | F HDA=0,x=00 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 | 1 | E | F | F HDA=4096,x=01
0 | 0 | 0 | 2 | E | F | F HDA=8192,x=10 0 | 0 | 0 | 2 | E | F | F HDA=8192,x=10
0 | 0 | 0 | 3 | E | F | F HDA=12288,x=11 0 | 0 | 0 | 3 | E | F | F HDA=12288,x=11]]></art
]]></artwork> work>
</figure> </figure>
</section> </section>
<section anchor="iso-range"> <section anchor="iso-range">
<name>ISO 3166-1 Countries Range</name> <name>ISO 3166-1 Countries Range</name>
<t>The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is s <t>The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is s
pecified and documented by IANA. Each Nation is assigned four RAAs that are left pecified and documented by IANA. Each Nation is assigned 4 RAAs that are left to
to the national authority for their purpose. For RAAs under this range, a short the national authority for their purpose. For RAAs under this range, a shorter
er prefix of <tt>2001:3x:xx00::/40</tt> MAY be delegated to each CAA, which cove prefix of <tt>2001:3x:xx00::/40</tt> <bcp14>MAY</bcp14> be delegated to each CAA
rs all 4 RAAs (and reserved HDAs) assigned to them.</t> , 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" sectionF ormat="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> <t>This range is set to IESG Approval (<xref section="4.10" sectionF ormat="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> <!-- [rfced] The text below has been removed as requested. However, please conf
<t>The CSV file found for the ISO to RAA mapping is on <eref tar irm that the info within the CSV file is not meant to be held in the IANA regist
get="https://github.com/ietf-wg-drip/draft-ietf-drip-registries/commit/a8da51bfc ry.
afcdf91878f8862c52830aa736782c9">GitHub</eref>. RFC Editor, please remove this n
ote after IANA initializes the registry but before publication.</t> <t indent="3">The CSV file found for the ISO to RAA mapping is o
</li> n <eref target="https://github.com/ietf-wg-drip/draft-ietf-drip-registries/commi
</ul> t/a8da51bfcafcdf91878f8862c52830aa736782c9">GitHub</eref>. RFC Editor, please re
move this note after IANA initializes the registry but before publication.</t>
-->
</section> </section>
<section anchor="experimental-range"> <section anchor="experimental-range">
<name>Private Range</name> <name>Private Range</name>
<t>If nibble-reversed lookup in DNS is desired it can only provided by private DNS servers as zone delegations from the global root will not be perf ormed 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 ra nge to any party (as per Private Use, <xref section="4.1" sectionFormat="of" tar get="RFC8126"/>).</t> <t>If nibble-reversed lookup in DNS is desired, it can only be provi ded 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 t his range may be used in like manner and IANA will not delegate any value in thi s 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 experi mentation and testing prior to request allocation or assignment from IANA.</t> <t>One anticipated acceptable use of the private range is for experi mentation and testing prior to request allocation or assignment from IANA.</t>
</section> </section>
</section> </section>
<section anchor="iana-hhit-type"> <section anchor="iana-hhit-type">
<!-- [rfced] May we update the section title of 6.2.2 to be plural? Note that w
e 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> <name>HHIT Entity Type</name>
<t>This document requests a new registry for HHIT Entity Type under th e <eref target="https://www.iana.org/assignments/drip">DRIP registry group</eref >.</t> <t>This document requests a new registry for HHIT Entity Type under th e <eref target="https://www.iana.org/assignments/drip" brackets="angle">"Drone R emote ID Protocol" registry group</eref>.</t>
<dl> <dl>
<dt>HHIT Entity Type:</dt> <dt>HHIT Entity Type:</dt>
<dd> <dd>
<t>numeric, field of the HHIT RRType to encode the HHIT Entity Typ e. All entries in this registry are under a First Come First Served (<xref secti on="4.4" sectionFormat="of" target="RFC8126"/>) policy.</t> <t>Numeric, field of the HHIT RRType to encode the HHIT Entity Typ e. All entries in this registry are under the First Come First Served policy (<x ref section="4.4" sectionFormat="of" target="RFC8126"/>).</t>
</dd> </dd>
</dl> </dl>
<section anchor="hhit-type-registry-fields"> <section anchor="hhit-type-registry-fields">
<name>HHIT Type Registry Fields</name> <name>HHIT Type Registry Fields</name>
<dl> <dl>
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>
<t>HHIT Type value of entry.</t> <t>HHIT Type value of the entry.</t>
</dd> </dd>
<dt>HHIT Type:</dt> <dt>HHIT Type:</dt>
<dd> <dd>
<t>Name of the entry and optional abbreviation.</t> <t>Name of the entry and an optional abbreviation.</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>Public document allocating the value and any additional infor mation such as semantics. This can be a URL pointing to an Internet-Draft, IETF RFC, or web-page among others.</t> <t>Public document allocating the value and any additional infor mation such as semantics. This can be a URL pointing to an Internet-Draft, IETF RFC, or web page among others.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="hhit-type-registration-form"> <section anchor="hhit-type-registration-form">
<name>HHIT Type Registration Form</name> <name>HHIT Type Registration Form</name>
<figure anchor="hhit-form"> <figure anchor="hhit-form">
<name>HHIT Type Registration Form</name> <name>HHIT Type Registration Form</name>
<artwork><![CDATA[ <artwork><![CDATA[
Value: Value:
HHIT Type: HHIT Type:
Reference: Reference:]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="initial-values"> <section anchor="initial-values">
<name>Initial Values</name> <name>Initial Values</name>
<t>The following values are defined by this document:</t> <t>The following values are defined by this document:</t>
<table anchor="hhit-initial"> <table anchor="hhit-initial">
<name>HHIT Entity Type Initial Values</name> <name>HHIT Entity Type Initial Values</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">HHIT Type</th> <th align="left">HHIT Type</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Not Defined</td> <td align="left">Not Defined</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">DRIP Identity Management Entity (DIME)</td> <td align="left">DRIP Identity Management Entity (DIME)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">Apex</td> <td align="left">Apex</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">9</td> <td align="left">9</td>
<td align="left">Registered Assigning Authority (RAA)</td> <td align="left">Registered Assigning Authority (RAA)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">13</td> <td align="left">13</td>
<td align="left">HHIT Domain Authority (HDA)</td> <td align="left">HHIT Domain Authority (HDA)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">16</td> <td align="left">16</td>
<td align="left">Unmanned Aircraft (UA)</td> <td align="left">Unmanned Aircraft (UA)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">17</td> <td align="left">17</td>
<td align="left">Ground Control Station (GCS)</td> <td align="left">Ground Control Station (GCS)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">18</td> <td align="left">18</td>
<td align="left">Unmanned Aircraft System (UAS)</td> <td align="left">Unmanned Aircraft System (UAS)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">19</td> <td align="left">19</td>
<td align="left">Remote Identification (RID) Module</td> <td align="left">Remote Identification (RID) Module</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">20</td> <td align="left">20</td>
<td align="left">Pilot</td> <td align="left">Pilot</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">21</td> <td align="left">21</td>
<td align="left">Operator</td> <td align="left">Operator</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">22</td> <td align="left">22</td>
<td align="left">Discovery &amp; Synchronization Service (DSS) </td> <td align="left">Discovery &amp; Synchronization Service (DSS) </td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">23</td> <td align="left">23</td>
<td align="left">UAS Service Supplier (USS)</td> <td align="left">UAS Service Supplier (USS)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">24</td> <td align="left">24</td>
<td align="left">Network RID Service Provider (SP)</td> <td align="left">Network RID Service Provider (SP)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">25</td> <td align="left">25</td>
<td align="left">Network RID Display Provider (DP)</td> <td align="left">Network RID Display Provider (DP)</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">26</td> <td align="left">26</td>
<td align="left">Supplemental Data Service Provider (SDSP)</td > <td align="left">Supplemental Data Service Provider (SDSP)</td >
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
<tr> <tr>
<td align="left">27</td> <td align="left">27</td>
<td align="left">Crowd Sourced RID Finder</td> <td align="left">Crowd Sourced RID Finder</td>
<td align="left">This RFC</td> <td align="left">RFC 9886</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="dns-operational-registration-considerations"> <section anchor="dns-operational-registration-considerations">
<name>DNS Operational &amp; Registration Considerations</name> <name>DNS Operational and Registration Considerations</name>
<t>The Registrar and Registry are commonly used concepts in the DNS. The <!-- [rfced] For clarity, we suggest updating the text as follows. Please revie
se components interface the DIME into the DNS hierarchy and thus operation SHOUL w and let us know if the text may be updated.
D follow best common practices, specifically in security (such as running DNSSEC
) as appropriate except when national regulations prevent it. <xref target="BCP2 Original:
37"/> provides suitable guidance.</t> These components interface the DIME into the DNS hierarchy and thus
<t>If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed an operation SHOULD follow best common practices, specifically in
d published. It SHOULD explain how DNSSEC has been deployed and what security me security (such as running DNSSEC) as appropriate except when national
asures are in place. <xref target="RFC6841"/> documents a Framework for DNSSEC P regulations prevent it.
olicies and DNSSEC Practice Statements. A self-signed entity (i.e. an entity tha
t self-signed it certificate as part of the HHIT RRType) MUST use DNSSEC.</t> Perhaps A:
<t>The interfaces and protocol specifications for registry-registrar int These components interface the DIME with the DNS hierarchy and thus
eractions are intentionally not specified in this document. These will depend on operation SHOULD follow best common practices, specifically in
nationally defined policy and prevailing local circumstances. It is expected re security (such as running DNSSEC) as appropriate except when national
gistry-registrar activity will use the Extensible Provisioning Protocol (EPP) <x regulations prevent it.
ref target="STD69"/> or equivalent. The registry SHOULD provide a lookup service
such as RDAP <xref target="STD95"/> or equivalent to publish public information Perhaps B:
about registered domain names.</t> These components connect the DIME with the DNS hierarchy and thus
<t>Decisions about DNS or registry best practices and other operational operation SHOULD follow best common practices, specifically in
matters that influence security SHOULD be made by the CAA, ideally in consultati security (such as running DNSSEC) as appropriate except when national
on with local stakeholders.</t> regulations prevent it.
<t>The guidance above is intended to reduce the likelihood of interopera -->
bility problems and minimize security and stability concerns. For instance, vali
dation and authentication of DNS responses depends on DNSSEC. If this is not use <t>The Registrar and Registry are commonly used concepts in the DNS. The
d, entities using DRIP will be vulnerable to DNS spoofing attacks and could be e se components interface the DIME into the DNS hierarchy and thus operation <bcp1
xposed to bogus data. DRIP DNS responses that have not been validated by DNSSEC 4>SHOULD</bcp14> follow best common practices, specifically in security (such as
could contain bogus data which have the potential to create serious security pro running DNSSEC) as appropriate except when national regulations prevent it. <xr
blems and operational concerns for DRIP entities. These threats include denial o ef target="BCP237"/> provides suitable guidance.</t>
f service attacks, replay attacks, impersonation or cloning of UAVs, hijacking o <t>If DNSSEC is used, a DNSSEC Practice Statement <bcp14>SHOULD</bcp14>
f DET registrations, injection of corrupt metadata and compromising established be developed and published. It <bcp14>SHOULD</bcp14> explain how DNSSEC has been
trust architecture/relationships. Some regulatory and legal considerations are e deployed and what security measures are in place. <xref target="RFC6841"/> docu
xpected to be simplified by providing a lookup service for access to public info ments a framework for DNSSEC policies and DNSSEC Practice Statements. A self-sig
rmation about registered domain names for DETs.</t> ned entity (i.e., an entity that self-signed its certificate as part of the HHIT
<t>When DNSSEC is not in use, due to the length of the ORCHID hash selec RRType) <bcp14>MUST</bcp14> use DNSSEC.</t>
ted for DETs (<xref section="3.5" sectionFormat="of" target="RFC9374"/>), client <t>The interfaces and protocol specifications for registry-registrar int
s MUST "walk" the tree of certificates locating each certificate by performing D eractions are intentionally not specified in this document. These will depend on
NS lookups of HHIT RRTypes for each DET verifying inclusion into the hierarchy. nationally defined policy and prevailing local circumstances. It is expected th
The collection of these certificates (which provide both signature protection fr at registry-registrar activity will use the Extensible Provisioning Protocol (EP
om the parent entity and the public key of the entity) is the only way without D P) <xref target="STD69"/> or equivalent. The registry <bcp14>SHOULD</bcp14> prov
NSSEC to prove valid registration.</t> ide a lookup service such as RDAP <xref target="STD95"/> or equivalent to publis
<t>The contents of the BRID RRType <tt>auth</tt> key, containing Endorse h public information about registered domain names.</t>
ments as described in <xref section="4.2" sectionFormat="of" target="RFC9575"/>, <t>Decisions about DNS or registry best practices and other operational
are a shadow of the X.509 certificate found in the HHIT RRType. The validation matters that influence security <bcp14>SHOULD</bcp14> be made by the CAA, ideall
of these Endorsements follow the guidelines written in <xref section="6.4.2" sec y in consultation with local stakeholders.</t>
tionFormat="of" target="RFC9575"/> for Broadcast RID Observers and when present <t>The guidance above is intended to reduce the likelihood of interopera
MUST also be validated.</t> bility problems and minimize security and stability concerns. For instance, vali
dation and authentication of DNS responses depends on DNSSEC. If this is not use
d, entities using DRIP will be vulnerable to DNS spoofing attacks and could be e
xposed to bogus data. DRIP DNS responses that have not been validated by DNSSEC
could contain bogus data that have the potential to create serious security prob
lems and operational concerns for DRIP entities. These threats include denial-of
-service attacks, replay attacks, impersonation or cloning of UAVs, hijacking of
DET registrations, injection of corrupt metadata, and compromising established
trust architecture/relationships. Some regulatory and legal considerations are e
xpected to be simplified by providing a lookup service for access to public info
rmation about registered domain names for DETs.</t>
<t>When DNSSEC is not in use, due to the length of the ORCHID hash selec
ted for DETs (<xref section="3.5" sectionFormat="of" target="RFC9374"/>), client
s <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 signatur
e protection from the parent entity and the public key of the entity) is the onl
y way without DNSSEC to prove valid registration.</t>
<t>The contents of the BRID RRType <tt>auth</tt> key, containing Endorse
ments 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" sec
tionFormat="of" target="RFC9575"/> for Broadcast RID Observers and when present
<bcp14>MUST</bcp14> also be validated.</t>
</section> </section>
<section anchor="det-public-key-exposure"> <section anchor="det-public-key-exposure">
<name>DET &amp; Public Key Exposure</name> <name>DET and Public Key Exposure</name>
<t>DETs are built upon asymmetric keys. As such the public key must be r evealed to enable clients to perform signature verifications. <xref target="RFC9 374"/> security considerations cover various attacks on such keys. While unlikel y, the forging of a corresponding private key is possible if given enough time ( and computational power).</t> <t>DETs are built upon asymmetric keys. As such the public key must be r evealed to enable clients to perform signature verifications. <xref target="RFC9 374"/> security considerations cover various attacks on such keys. While unlikel y, the forging of a corresponding private key is possible if given enough time ( and computational power).</t>
<t>When practical, it is RECOMMENDED that no RRTypes under a DET's speci <t>When practical, it is <bcp14>RECOMMENDED</bcp14> that no RRTypes unde
fic domain name be published unless and until it is required for use by other pa r a DET's specific domain name be published unless and until it is required for
rties. Such action would cause at least the HHIT RRType to not be in DNS, protec use by other parties. Such action would cause at least the HHIT RRType to not be
ting the public key in the certificate from being exposed before its needed. The in the DNS, protecting the public key in the certificate from being exposed bef
combination of this "just in time" publishing mechanism and DNSSEC is out of sc ore its needed. The combination of this "just in time" publishing mechanism and
ope for this document.</t> DNSSEC is out of scope for this document.</t>
<t>Optimally this requires that the UAS somehow signal the DIME that a f <t>Optimally this requires that the UAS somehow signal to the DIME that
light using a Specific Session ID will soon be underway or complete. It may also a flight using a Specific Session ID will soon be underway or complete. It may a
be facilitated under UTM if the USS (which may or may not be a DIME) signals wh lso be facilitated under UTM if the USS (which may or may not be a DIME) signals
en a given operation using a Session ID goes active.</t> when a given operation using a Session ID goes active.</t>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consu
lting, LLC) for their early work on the DRIP registries concept. Their early con
tributions laid the foundations for the content and processes of this architectu
re and document.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-drip-dki" to="drip-dki"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC4648"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 648.xml"/>
<title>The Base16, Base32, and Base64 Data Encodings</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> 949.xml"/>
<date month="October" year="2006"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 374.xml"/>
<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 da
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</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 forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange 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="Wiethuecht
er"/>
<author fullname="A. Gurtov" initials="A." surname="Gurtov"/>
<date month="March" year="2023"/>
<abstract>
<t>This document describes the use of Hierarchical Host Identity T
ags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identif
iers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tra
cking.</t>
<t>Within the context of RID, HHITs will be called DRIP Entity Tag
s (DETs). HHITs provide claims to the included explicit hierarchy that provides
registry (via, for example, DNS, RDAP) discovery for third-party identifier endo
rsement.</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>
<reference anchor="F3411" target="https://www.astm.org/f3411-22a.html"> <reference anchor="F3411" target="https://www.astm.org/f3411-22a.html">
<front> <front>
<title>Standard Specification for Remote ID and Tracking</title> <title>Standard Specification for Remote ID and Tracking</title>
<author> <author>
<organization>ASTM International</organization> <organization>ASTM International</organization>
</author> </author>
<date year="2022" month="July"/> <date year="2022" month="July"/>
</front> </front>
<seriesInfo name="ASTM" value="F3411-22A"/> <seriesInfo name="ASTM" value="F3411-22A"/>
<seriesInfo name="DOI" value="10.1520/F3411-22A"/> <seriesInfo name="DOI" value="10.1520/F3411-22A"/>
</reference> </reference>
<!-- [rfced] [ISO-3166-2] Please review.
The URL below goes to a page titled “ISO 3166
Country Codes”, but this reference appears to be specifically to Part
1 of ISO 3166 (ISO 3166-1).
We found the following URL for the most up-to-date version of ISO 3166-1
(ISO 3166-1:2020): https://www.iso.org/standard/72482.html
Would you like to update this reference to point to the most
up-to-date version of ISO 3166-1? Or would you like this reference to
point to the more general page for ISO 3166?
Current:
[ISO3166-1]
ISO, "Codes for the representation of names of countries and 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-cod
es.html>.
-->
<reference anchor="ISO3166-1" target="https://www.iso.org/iso-3166-count ry-codes.html"> <reference anchor="ISO3166-1" target="https://www.iso.org/iso-3166-count ry-codes.html">
<front> <front>
<title>Codes for the representation of names of countries and their subdivisions</title> <title>Codes for the representation of names of countries and their subdivisions - Part 1: Country code</title>
<author> <author>
<organization>International Standards Organization (ISO)</organiza tion> <organization>ISO</organization>
</author> </author>
<date year="2020" month="August"/> <date year="2020" month="August"/>
</front> </front>
<seriesInfo name="ISO" value="3166-1:2020"/> <seriesInfo name="ISO" value="3166-1:2020"/>
</reference> </reference>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
le> 174.xml"/>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="drip-dki"> <!-- [drip-dki]
<front> draft-ietf-drip-dki-09
<title>The DRIP DET public Key Infrastructure</title> IESG State: I-D Exists as of 10/22/25
<author fullname="Robert Moskowitz" initials="R." surname="Moskowitz -->
"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<organization>HTT Consulting</organization> ietf-drip-dki.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
<author fullname="Stuart W. Card" initials="S. W." surname="Card"> 237.xml"/>
<organization>AX Enterprize, LLC</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
</author> 13.xml"/>
<date day="22" month="April" year="2025"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
<abstract> 69.xml"/>
<t> The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
a 95.xml"/>
specific variant of classic Public Key Infrastructures (PKI) where <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
the organization is around the DET, in place of X.520 Distinguished 88.xml"/>
Names. Further, the DKI uses DRIP Endorsements in place of X.509 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
certificates for establishing trust within the DKI. 280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
There are two X.509 profiles for shadow PKI behind the DKI, with many 841.xml"/>
of their X.509 fields mirroring content in the DRIP Endorsements. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
These PKIs can at times be used where X.509 is expected and non- 126.xml"/>
constrained communication links are available that can handle their <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
larger size. It is recommended that a DRIP deployment implement both 610.xml"/>
of these along side the Endorsement trees. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
153.xml"/>
C509 (CBOR) encoding of all X.509 certificates are also provided as <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
an alternative for where there are gains in reduced object size. 434.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</t> 575.xml"/>
</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/rf
c9364">
<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 t
hat 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 or
igin authentication of DNS data is the best current practice. A third purpose is
to provide a single reference for other documents that want to refer 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/s
td13">
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rf
c1034">
<front>
<title>Domain names - concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetr
is"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name S
ystem. It obsoletes RFC-882. This memo describes the domain style names and thei
r 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 the
m.</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/rf
c1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetr
is"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and for
mat 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/s
td69">
<reference anchor="RFC5730" target="https://www.rfc-editor.org/info/rf
c5730">
<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 pr
otocol for the provisioning and management of objects stored in a shared central
repository. Specified in XML, the protocol defines generic object management op
erations and an extensible framework that maps protocol operations to objects. T
his document includes a protocol specification, an object mapping template, and
an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRA
CK]</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/rf
c5731">
<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 comma
nd syntax and semantics as applied to domain 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/rf
c5732">
<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 management of Internet host names stored i
n a shared central repository. Specified in XML, the mapping 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/rf
c5733">
<front>
<title>Extensible Provisioning Protocol (EPP) Contact Mapping</tit
le>
<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 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/rf
c5734">
<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 Protoc
ol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) con
nection. This mapping requires use of the Transport Layer Security (TLS) protoco
l 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/s
td95">
<reference anchor="RFC7480" target="https://www.rfc-editor.org/info/rf
c7480">
<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 transport
ed using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to
the very old WHOIS protocol. The purpose of this document is to clarify the use
of standard HTTP mechanisms for this application.</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/rf
c7481">
<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 "RESTfu
l" web services to retrieve registration metadata from Domain Name and Regional
Internet Registries. This document describes information security services, incl
uding access control, authentication, authorization, availability, data confiden
tiality, 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/rf
c9082">
<front>
<title>Registration Data Access Protocol (RDAP) Query Format</titl
e>
<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 UR
Ls that may be used to retrieve registration information from registries (includ
ing both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs))
using "RESTful" web access patterns. These uniform patterns define the query syn
tax for the Registration Data Access Protocol (RDAP). This document obsoletes RF
C 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/rf
c9083">
<front>
<title>JSON Responses for the Registration Data Access Protocol (R
DAP)</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 reg
istration information maintained by Regional Internet Registries (RIRs) and Doma
in Name Registries (DNRs). These data structures are used to form Registration D
ata 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/rf
c9224">
<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 D
ata Access Protocol (RDAP) server is authoritative to answer queries for a reque
sted scope, such as domain names, IP addresses, or Autonomous System numbers. Th
is 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/s
td88">
<reference anchor="RFC3596" target="https://www.rfc-editor.org/info/rf
c3596">
<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 need to be made to the
Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The chan
ges 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 typ
es that return Internet addresses as part of additional section processing. The
extensions are designed to be compatible with existing applications and, in part
icular, 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 Cert
ificate 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 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [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 Statement
s</title>
<author fullname="F. Ljunggren" initials="F." surname="Ljunggren"/>
<author fullname="AM. Eklund Lowinder" initials="AM." surname="Eklun
d 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 Sec
urity Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domai
n 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 t
opics that should be considered for inclusion into a DNSSEC Policy definition an
d Practice Statement. This document is not an Internet Standards Track specifica
tion; 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 con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations 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 des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</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 Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="RFC9153">
<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="Wiethuecht
er"/>
<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 for solution
s produced by the Drone Remote Identification Protocol (DRIP) Working Group. The
se solutions will support Unmanned Aircraft System Remote Identification and tra
cking (UAS RID) for security, safety, and other purposes (e.g., initiation of id
entity-based network sessions supporting UAS applications). DRIP will facilitate
use of existing Internet resources to support RID and to enable enhanced relate
d services, and it will enable online and offline verification that RID informat
ion 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</tit
le>
<author fullname="S. Card" initials="S." surname="Card"/>
<author fullname="A. Wiethuechter" initials="A." surname="Wiethuecht
er"/>
<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"/>
<date month="July" year="2023"/>
<abstract>
<t>This document describes an architecture for protocols and servi
ces to support Unmanned Aircraft System Remote Identification and tracking (UAS
RID), plus UAS-RID-related communications. This architecture adheres to the requ
irements listed in the Drone Remote Identification Protocol (DRIP) Requirements
document (RFC 9153).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9434"/>
<seriesInfo name="DOI" value="10.17487/RFC9434"/>
</reference>
<reference anchor="RFC9575">
<front>
<title>DRIP Entity Tag (DET) Authentication Formats and Protocols fo
r Broadcast Remote Identification (RID)</title>
<author fullname="A. Wiethuechter" initials="A." role="editor" surna
me="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 pol
icies and periodic access to registries, augments Unmanned Aircraft System (UAS)
Remote Identification (RID), enabling local real-time assessment of trustworthi
ness of received RID messages and observed UAS, even by Observers lacking Intern
et access. This document defines DRIP message types and formats to be sent in Br
oadcast RID Authentication Messages to verify that attached and recently detache
d messages were signed by the registered owner of the DRIP Entity Tag (DET) clai
med.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9575"/>
<seriesInfo name="DOI" value="10.17487/RFC9575"/>
</reference>
</references> </references>
</references> </references>
<?line 550?>
<section anchor="example-zone-files-rrtype-contents"> <section anchor="example-zone-files-rrtype-contents">
<name>Example Zone Files &amp; RRType Contents</name> <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 co llisions with production deployments an apex of <tt>ip6.example.com.</tt> is use d instead of <tt>ip6.arpa.</tt>. All hexadecimal strings in the examples are bro ken into the lengths of a word, for document formatting purposes.</t> <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 co llisions with production deployments an apex of <tt>ip6.example.com.</tt> is use d instead of <tt>ip6.arpa.</tt>. All hexadecimal strings in the examples are bro ken 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> <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"> <section anchor="example-raa">
<name>Example RAA</name> <name>Example RAA</name>
<section anchor="raa-hhits"> <section anchor="raa-hhits">
<name>Authentication HHIT</name> <name>Authentication HHIT</name>
<figure anchor="raa-rr-zone"> <figure anchor="raa-rr-zone">
<name>RAA Auth HHIT RRType Example</name> <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. $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 ( 7.b.0.a.1.9.e.1.7.5.1.a.0.6.e.5. IN HHIT (
gwppM2ZmOCAwMDAwWQFGMIIBQjCB9aAD gwppM2ZmOCAwMDAwWQFGMIIBQjCB9aAD
AgECAgE1MAUGAytlcDArMSkwJwYDVQQD AgECAgE1MAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
NTcxZTkxYTBiNzAeFw0yNTA0MDkyMDU2 NTcxZTkxYTBiNzAeFw0yNTA0MDkyMDU2
MjZaFw0yNTA0MDkyMTU2MjZaMB0xGzAZ MjZaFw0yNTA0MDkyMTU2MjZaMB0xGzAZ
BgNVBAMMEkRSSVAtUkFBLUEtMTYzNzYt BgNVBAMMEkRSSVAtUkFBLUEtMTYzNzYt
MDAqMAUGAytlcAMhAJmQ1bBLcqGAZtQJ MDAqMAUGAytlcAMhAJmQ1bBLcqGAZtQJ
K1LH1JlPt8Fr1+jB9ED/qNBP8eE/o0ww K1LH1JlPt8Fr1+jB9ED/qNBP8eE/o0ww
SjAPBgNVHRMBAf8EBTADAQH/MDcGA1Ud SjAPBgNVHRMBAf8EBTADAQH/MDcGA1Ud
EQEB/wQtMCuHECABAD/+AAAFXmChVx6R EQEB/wQtMCuHECABAD/+AAAFXmChVx6R
oLeGF2h0dHBzOi8vcmFhLmV4YW1wbGUu oLeGF2h0dHBzOi8vcmFhLmV4YW1wbGUu
Y29tMAUGAytlcANBALUPjhIB3rwqXQep Y29tMAUGAytlcANBALUPjhIB3rwqXQep
r9/VDB+hhtwuWZIw1OUkEuDrF6DCkgc7 r9/VDB+hhtwuWZIw1OUkEuDrF6DCkgc7
5widXnXa5/uDfdKL7dZ83mPHm2Tf32Dv 5widXnXa5/uDfdKL7dZ83mPHm2Tf32Dv
b8AzEw8= b8AzEw8=
) )]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="raa-rr-cbor"/> shows the CBOR decoded RDATA in the HH IT RRType found in <xref target="raa-rr-zone"/>.</t> <t><xref target="raa-rr-cbor"/> shows the CBOR decoded RDATA in the HH IT RRType found in <xref target="raa-rr-zone"/>.</t>
<figure anchor="raa-rr-cbor"> <figure anchor="raa-rr-cbor">
<name>2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded HHIT RRType CBOR</n ame> <name>2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded HHIT RRType CBOR</n ame>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
[ [
10, # Reserved (RAA Auth from DKI) 10, # Reserved (RAA Auth from DKI)
"3ff8 0000", "3ff8 0000",
h'308201423081F5A00302010202013530 h'308201423081F5A00302010202013530
0506032B6570302B312930270603550403 0506032B6570302B312930270603550403
0C20323030313030336666653030303030 0C20323030313030336666653030303030
3535653630613135373165393161306237 3535653630613135373165393161306237
301E170D3235303430393230353632365A 301E170D3235303430393230353632365A
170D3235303430393231353632365A301D 170D3235303430393231353632365A301D
311B301906035504030C12445249502D52 311B301906035504030C12445249502D52
skipping to change at line 1116 skipping to change at line 893
D04FF1E13FA34C304A300F0603551D1301 D04FF1E13FA34C304A300F0603551D1301
01FF040530030101FF30370603551D1101 01FF040530030101FF30370603551D1101
01FF042D302B87102001003FFE0000055E 01FF042D302B87102001003FFE0000055E
60A1571E91A0B7861768747470733A2F2F 60A1571E91A0B7861768747470733A2F2F
7261612E6578616D706C652E636F6D3005 7261612E6578616D706C652E636F6D3005
06032B6570034100B50F8E1201DEBC2A5D 06032B6570034100B50F8E1201DEBC2A5D
07A9AFDFD50C1FA186DC2E599230D4E524 07A9AFDFD50C1FA186DC2E599230D4E524
12E0EB17A0C292073BE7089D5E75DAE7FB 12E0EB17A0C292073BE7089D5E75DAE7FB
837DD28BEDD67CDE63C79B64DFDF60EF6F 837DD28BEDD67CDE63C79B64DFDF60EF6F
C033130F' C033130F'
] ]]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="raa-rr-cert"/> shows the decoded DER X.509 found in < xref target="raa-rr-cbor"/>.</t> <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"> <figure anchor="raa-rr-cert">
<name>2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded Certificate</name> <name>2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded Certificate</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 53 (0x35) Serial Number: 53 (0x35)
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Issuer: CN = 2001003ffe0000055e60a1571e91a0b7 Issuer: CN = 2001003ffe0000055e60a1571e91a0b7
Validity Validity
Not Before: Apr 9 20:56:26 2025 GMT Not Before: Apr 9 20:56:26 2025 GMT
Not After : Apr 9 21:56:26 2025 GMT Not After : Apr 9 21:56:26 2025 GMT
Subject: CN = DRIP-RAA-A-16376-0 Subject: CN = DRIP-RAA-A-16376-0
skipping to change at line 1151 skipping to change at line 927
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Subject Alternative Name: critical X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:5:5E60:A157:1E91:A0B7, IP Address:2001:3F:FE00:5:5E60:A157:1E91:A0B7,
URI:https://raa.example.com URI:https://raa.example.com
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Signature Value: Signature Value:
b5:0f:8e:12:01:de:bc:2a:5d:07:a9:af:df:d5:0c:1f:a1:86: 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: 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: 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 64:df:df:60:ef:6f:c0:33:13:0f]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="delegation-of-hda"> <section anchor="delegation-of-hda">
<name>Delegation of HDA</name> <name>Delegation of HDA</name>
<figure> <figure>
<name>HDA Delegation Example</name> <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. $ORIGIN c.d.f.f.3.0.0.1.0.0.2.ip6.example.com.
a.0.0. IN NS ns1.hda-10.example.com a.0.0. IN NS ns1.hda-10.example.com]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="example-hda"> <section anchor="example-hda">
<name>Example HDA</name> <name>Example HDA</name>
<section anchor="hda-hhits"> <section anchor="hda-hhits">
<name>Authentication &amp; Issue HHITs</name> <name>Authentication and Issue HHITs</name>
<figure anchor="hda-rr-zone"> <figure anchor="hda-rr-zone">
<name>HDA Auth/Issue HHIT RRType Example</name> <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. $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 ( 0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. IN HHIT (
gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD
AgECAgFfMAUGAytlcDArMSkwJwYDVQQD AgECAgFfMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz
MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa
BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt
MTAwKjAFBgMrZXADIQDOaB424RQa61YN MTAwKjAFBgMrZXADIQDOaB424RQa61YN
bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM
skipping to change at line 1207 skipping to change at line 981
BgNVBAMME0RSSVAtSERBLUktMTYzNzYt BgNVBAMME0RSSVAtSERBLUktMTYzNzYt
MTAwKjAFBgMrZXADIQCCM/2utQaLwUhZ MTAwKjAFBgMrZXADIQCCM/2utQaLwUhZ
0ROg7fz43AeBTj3Sdl5rW4LgTQcFl6NM 0ROg7fz43AeBTj3Sdl5rW4LgTQcFl6NM
MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV
HREBAf8ELTArhxAgAQA//gAKBSYO1Ddr HREBAf8ELTArhxAgAQA//gAKBSYO1Ddr
JW4ohhdodHRwczovL2hkYS5leGFtcGxl JW4ohhdodHRwczovL2hkYS5leGFtcGxl
LmNvbTAFBgMrZXADQQBa8lZyftxHJqDF LmNvbTAFBgMrZXADQQBa8lZyftxHJqDF
Vgv4Rt+cMUmc8aQwet4UZdO3yQOB9uq4 Vgv4Rt+cMUmc8aQwet4UZdO3yQOB9uq4
sLVAScaZCWjC0nmeRkgVRhize1esfyi3 sLVAScaZCWjC0nmeRkgVRhize1esfyi3
RRU44IAE RRU44IAE
) )]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="hdaa-rr-cbor"/> shows the CBOR decoded RDATA in the H HIT RRType found in <xref target="hda-rr-zone"/>.</t> <t><xref target="hdaa-rr-cbor"/> shows the CBOR decoded RDATA in the H HIT RRType found in <xref target="hda-rr-zone"/>.</t>
<figure anchor="hdaa-rr-cbor"> <figure anchor="hdaa-rr-cbor">
<name>2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded HHIT RRType CBOR</ name> <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) 14, # Reserved (HDA Auth from DKI)
"3ff8 000a", "3ff8 000a",
h'308201433081F6A00302010202015F30 h'308201433081F6A00302010202015F30
0506032B6570302B312930270603550403 0506032B6570302B312930270603550403
0C20323030313030336666653030303030 0C20323030313030336666653030303030
3535653630613135373165393161306237 3535653630613135373165393161306237
301E170D3235303430393231303331395A 301E170D3235303430393231303331395A
170D3235303430393232303331395A301E 170D3235303430393232303331395A301E
311C301A06035504030C13445249502D48 311C301A06035504030C13445249502D48
skipping to change at line 1237 skipping to change at line 1010
0A380101803FA34C304A300F0603551D13 0A380101803FA34C304A300F0603551D13
0101FF040530030101FF30370603551D11 0101FF040530030101FF30370603551D11
0101FF042D302B87102001003FFE000A05 0101FF042D302B87102001003FFE000A05
6615EE45D42709A0861768747470733A2F 6615EE45D42709A0861768747470733A2F
2F7261612E6578616D706C652E636F6D30 2F7261612E6578616D706C652E636F6D30
0506032B6570034100213293923A680C90 0506032B6570034100213293923A680C90
96357FE07D9D381AC148CAE18104441B5C 96357FE07D9D381AC148CAE18104441B5C
CCC9271C390EA305F4CA76DA2CDEB44D87 CCC9271C390EA305F4CA76DA2CDEB44D87
BD86A37AF8227748DF1BAC991EDE1A4C82 BD86A37AF8227748DF1BAC991EDE1A4C82
8AEF843909' 8AEF843909'
] ]]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="hdaa-rr-cert"/> shows the decoded DER X.509 found in <xref target="hdaa-rr-cbor"/>.</t> <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"> <figure anchor="hdaa-rr-cert">
<name>2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded Certificate</name> <name>2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded Certificate</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 95 (0x5f) Serial Number: 95 (0x5f)
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Issuer: CN = 2001003ffe0000055e60a1571e91a0b7 Issuer: CN = 2001003ffe0000055e60a1571e91a0b7
Validity Validity
Not Before: Apr 9 21:03:19 2025 GMT Not Before: Apr 9 21:03:19 2025 GMT
Not After : Apr 9 22:03:19 2025 GMT Not After : Apr 9 22:03:19 2025 GMT
Subject: CN = DRIP-HDA-A-16376-10 Subject: CN = DRIP-HDA-A-16376-10
skipping to change at line 1272 skipping to change at line 1045
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Subject Alternative Name: critical X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:A05:6615:EE45:D427:9A0, IP Address:2001:3F:FE00:A05:6615:EE45:D427:9A0,
URI:https://raa.example.com URI:https://raa.example.com
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Signature Value: Signature Value:
21:32:93:92:3a:68:0c:90:96:35:7f:e0:7d:9d:38:1a:c1:48: 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: 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: 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 1e:de:1a:4c:82:8a:ef:84:39:09]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="hdai-rr-cbor"/> shows the CBOR decoded RDATA in the H HIT RRType found in <xref target="hda-rr-zone"/>.</t> <t><xref target="hdai-rr-cbor"/> shows the CBOR decoded RDATA in the H HIT RRType found in <xref target="hda-rr-zone"/>.</t>
<figure anchor="hdai-rr-cbor"> <figure anchor="hdai-rr-cbor">
<name>2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded HHIT RRType CBOR< /name> <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) 15, # Reserved (HDA Issue from DKI)
"3ff8 000a", "3ff8 000a",
h'308201433081F6A00302010202015830 h'308201433081F6A00302010202015830
0506032B6570302B312930270603550403 0506032B6570302B312930270603550403
0C20323030313030336666653030306130 0C20323030313030336666653030306130
3536363135656534356434323730396130 3536363135656534356434323730396130
301E170D3235303430393231303531345A 301E170D3235303430393231303531345A
170D3235303430393232303531345A301E 170D3235303430393232303531345A301E
311C301A06035504030C13445249502D48 311C301A06035504030C13445249502D48
skipping to change at line 1302 skipping to change at line 1074
82E04D070597A34C304A300F0603551D13 82E04D070597A34C304A300F0603551D13
0101FF040530030101FF30370603551D11 0101FF040530030101FF30370603551D11
0101FF042D302B87102001003FFE000A05 0101FF042D302B87102001003FFE000A05
260ED4376B256E28861768747470733A2F 260ED4376B256E28861768747470733A2F
2F6864612E6578616D706C652E636F6D30 2F6864612E6578616D706C652E636F6D30
0506032B65700341005AF256727EDC4726 0506032B65700341005AF256727EDC4726
A0C5560BF846DF9C31499CF1A4307ADE14 A0C5560BF846DF9C31499CF1A4307ADE14
65D3B7C90381F6EAB8B0B54049C6990968 65D3B7C90381F6EAB8B0B54049C6990968
C2D2799E4648154618B37B57AC7F28B745 C2D2799E4648154618B37B57AC7F28B745
1538E08004' 1538E08004'
] ]]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="hdai-rr-cert"/> shows the decoded DER X.509 found in <xref target="hdai-rr-cbor"/>.</t> <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"> <figure anchor="hdai-rr-cert">
<name>2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate</name > <name>2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate</name >
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 88 (0x58) Serial Number: 88 (0x58)
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Issuer: CN = 2001003ffe000a056615ee45d42709a0 Issuer: CN = 2001003ffe000a056615ee45d42709a0
Validity Validity
Not Before: Apr 9 21:05:14 2025 GMT Not Before: Apr 9 21:05:14 2025 GMT
Not After : Apr 9 22:05:14 2025 GMT Not After : Apr 9 22:05:14 2025 GMT
Subject: CN = DRIP-HDA-I-16376-10 Subject: CN = DRIP-HDA-I-16376-10
skipping to change at line 1337 skipping to change at line 1108
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Subject Alternative Name: critical X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:A05:260E:D437:6B25:6E28, IP Address:2001:3F:FE00:A05:260E:D437:6B25:6E28,
URI:https://hda.example.com URI:https://hda.example.com
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Signature Value: Signature Value:
5a:f2:56:72:7e:dc:47:26:a0:c5:56:0b:f8:46:df:9c:31:49: 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: 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: 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 ac:7f:28:b7:45:15:38:e0:80:04]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="registratant-hhit-brid"> <section anchor="registratant-hhit-brid">
<name>Registratant HHIT &amp; BRID</name> <name>Registratant HHIT and BRID</name>
<figure anchor="uas-rr-zone"> <figure anchor="uas-rr-zone">
<name>Registrant HHIT/BRID RRType Example</name> <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. $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 ( 2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN HHIT (
gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD
AgECAgFUMAUGAytlcDArMSkwJwYDVQQD AgECAgFUMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0 DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0
Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz
MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF
BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5 BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5
+drcW88GHqxPDOp56Oh3+qM7MDkwNwYD +drcW88GHqxPDOp56Oh3+qM7MDkwNwYD
VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp
skipping to change at line 1388 skipping to change at line 1158
guBNBwWXIAEAP/4ACgVmFe5F1CcJoIjy guBNBwWXIAEAP/4ACgVmFe5F1CcJoIjy
CriJCxAyAWTOHPmlHL02MKSpsHviiTze CriJCxAyAWTOHPmlHL02MKSpsHviiTze
qwBH9K/Rrz41CYix9HazAIOAZO8FcfU5 qwBH9K/Rrz41CYix9HazAIOAZO8FcfU5
M+WLLJZoaQWBHnMbTQwFWIkB3OL2Z+zw M+WLLJZoaQWBHnMbTQwFWIkB3OL2Z+zw
9mcgAQA//gAKBRMIJGmaS8ayyS4vnZfo 9mcgAQA//gAKBRMIJGmaS8ayyS4vnZfo
lg+bXxZU+LCQOfna3FvPBh6sTwzqeejo lg+bXxZU+LCQOfna3FvPBh6sTwzqeejo
d/ogAQA//gAKBSYO1DdrJW4ogOfc8jTi d/ogAQA//gAKBSYO1DdrJW4ogOfc8jTi
mYLmTOOyFZoUx2jOOwtB1jnqUJr6bYaw mYLmTOOyFZoUx2jOOwtB1jnqUJr6bYaw
MoPrR3MlKGBGWsVz1yXNqUURoCqYdwsY MoPrR3MlKGBGWsVz1yXNqUURoCqYdwsY
e61vd5i6YJqnAQ== e61vd5i6YJqnAQ==
) )]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="uas-rr-cbor"/> shows the CBOR decoded RDATA in the HH IT RRType found in <xref target="uas-rr-zone"/>.</t> <t><xref target="uas-rr-cbor"/> shows the CBOR decoded RDATA in the HH IT RRType found in <xref target="uas-rr-zone"/>.</t>
<figure anchor="uas-rr-cbor"> <figure anchor="uas-rr-cbor">
<name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded HHIT RRType CBOR< /name> <name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded HHIT RRType CBOR< /name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
[ [
18, # Uncrewed Aircraft System (UAS) 18, # Uncrewed Aircraft System (UAS)
"3ff8 000a", "3ff8 000a",
h'308201143081C7A00302010202015430 h'308201143081C7A00302010202015430
0506032B6570302B312930270603550403 0506032B6570302B312930270603550403
0C20323030313030336666653030306130 0C20323030313030336666653030306130
3532363065643433373662323536653238 3532363065643433373662323536653238
301E170D3235303430393231313330305A 301E170D3235303430393231313330305A
170D3235303430393232313330305A3000 170D3235303430393232313330305A3000
302A300506032B6570032100C92E2F9D97 302A300506032B6570032100C92E2F9D97
E8960F9B5F1654F8B09039F9DADC5BCF06 E8960F9B5F1654F8B09039F9DADC5BCF06
1EAC4F0CEA79E8E877FAA33B3039303706 1EAC4F0CEA79E8E877FAA33B3039303706
03551D110101FF042D302B87102001003F 03551D110101FF042D302B87102001003F
FE000A05130824699A4BC6B28617687474 FE000A05130824699A4BC6B28617687474
70733A2F2F6864612E6578616D706C652E 70733A2F2F6864612E6578616D706C652E
636F6D300506032B6570034100D036DC76 636F6D300506032B6570034100D036DC76
7802EFF041FDA2E36662E27A8D191420DB 7802EFF041FDA2E36662E27A8D191420DB
77F288C40CBEDD7D8AB53E09B68755C513 77F288C40CBEDD7D8AB53E09B68755C513
0F02437AA34D3C81A71B35F4C6F29F67A4 0F02437AA34D3C81A71B35F4C6F29F67A4
470379885EB25DA305' 470379885EB25DA305'
] ]]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="uas-rr-cert"/> shows the decoded DER X.509 found in < xref target="uas-rr-cbor"/>.</t> <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"> <figure anchor="uas-rr-cert">
<name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded Certificate</name > <name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded Certificate</name >
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 84 (0x54) Serial Number: 84 (0x54)
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Issuer: CN = 2001003ffe000a05260ed4376b256e28 Issuer: CN = 2001003ffe000a05260ed4376b256e28
Validity Validity
Not Before: Apr 9 21:13:00 2025 GMT Not Before: Apr 9 21:13:00 2025 GMT
Not After : Apr 9 22:13:00 2025 GMT Not After : Apr 9 22:13:00 2025 GMT
Subject: Subject:
skipping to change at line 1448 skipping to change at line 1216
77:fa 77:fa
X509v3 extensions: X509v3 extensions:
X509v3 Subject Alternative Name: critical X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:A05:1308:2469:9A4B:C6B2, IP Address:2001:3F:FE00:A05:1308:2469:9A4B:C6B2,
URI:https://hda.example.com URI:https://hda.example.com
Signature Algorithm: ED25519 Signature Algorithm: ED25519
Signature Value: Signature Value:
d0:36:dc:76:78:02:ef:f0:41:fd:a2:e3:66:62:e2:7a:8d:19: 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: 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: 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 a4:47:03:79:88:5e:b2:5d:a3:05]]></sourcecode>
]]></artwork>
</figure> </figure>
<t><xref target="uas-rr-brid"/> shows the CBOR decoded RDATA of the BR ID RRType in <xref target="uas-rr-zone"/>.</t> <t><xref target="uas-rr-brid"/> shows the CBOR decoded RDATA of the BR ID RRType in <xref target="uas-rr-zone"/>.</t>
<figure anchor="uas-rr-brid"> <figure anchor="uas-rr-brid">
<name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID RRType CBOR< /name> <name>2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID RRType CBOR< /name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
{ {
0: 0, 0: 0,
1: [4, h'012001003FFE000A05130824699A4BC6B2'], 1: [4, h'012001003FFE000A05130824699A4BC6B2'],
2: [ 2: [
5, 5,
h'01FADEF6670AEDF6672001003FFE0000 h'01FADEF6670AEDF6672001003FFE0000
055E60A1571E91A0B79990D5B04B72A180 055E60A1571E91A0B79990D5B04B72A180
66D4092B52C7D4994FB7C16BD7E8C1F440 66D4092B52C7D4994FB7C16BD7E8C1F440
FFA8D04FF1E13F2001003FFE0000055E60 FFA8D04FF1E13F2001003FFE0000055E60
A1571E91A0B7BC2F66D4982EBD7B7B5B6A A1571E91A0B7BC2F66D4982EBD7B7B5B6A
skipping to change at line 1500 skipping to change at line 1267
h'01DCE2F667ECF0F6672001003FFE000A h'01DCE2F667ECF0F6672001003FFE000A
05130824699A4BC6B2C92E2F9D97E8960F 05130824699A4BC6B2C92E2F9D97E8960F
9B5F1654F8B09039F9DADC5BCF061EAC4F 9B5F1654F8B09039F9DADC5BCF061EAC4F
0CEA79E8E877FA2001003FFE000A05260E 0CEA79E8E877FA2001003FFE000A05260E
D4376B256E2880E7DCF234E29982E64CE3 D4376B256E2880E7DCF234E29982E64CE3
B2159A14C768CE3B0B41D639EA509AFA6D B2159A14C768CE3B0B41D639EA509AFA6D
86B03283EB4773252860465AC573D725CD 86B03283EB4773252860465AC573D725CD
A94511A02A98770B187BAD6F7798BA609A A94511A02A98770B187BAD6F7798BA609A
A701' A701'
] ]
} }]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Stuart Card"/> (AX Enterprize, LLC) and <c
ontact fullname="Bob Moskowitz"/> (HTT Consulting, LLC) for their early work on
the DRIP registries concept. Their early contributions laid the foundation for t
he content and processes of this architecture and document.</t>
</section>
</back> </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. Lo
wercase is far more common in RFCs. The majority of uppercase instances are whe
re 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> </rfc>
 End of changes. 126 change blocks. 
1337 lines changed or deleted 614 lines changed or added

This html diff was produced by rfcdiff 1.48.