rfc9886v1.txt		rfc9886.txt
	skipping to change at line 80 ¶		skipping to change at line 80 ¶
	5.1. HHIT Resource Record		5.1. HHIT Resource Record
	5.1.1. Text Representation		5.1.1. Text Representation
	5.1.2. Field Descriptions		5.1.2. Field Descriptions
	5.2. UAS Broadcast RID Resource Record		5.2. UAS Broadcast RID Resource Record
	5.2.1. Text Representation		5.2.1. Text Representation
	5.2.2. Field Descriptions		5.2.2. Field Descriptions
	6. IANA Considerations		6. IANA Considerations
	6.1. DET Prefix Delegation		6.1. DET Prefix Delegation
	6.2. IANA DRIP Registry		6.2. IANA DRIP Registry
	6.2.1. DRIP RAA Allocations		6.2.1. DRIP RAA Allocations
	6.2.2. HHIT Entity Type		6.2.2. HHIT Entity Types
	7. Security Considerations		7. Security Considerations
	7.1. DNS Operational and Registration Considerations		7.1. DNS Operational and Registration Considerations
	7.2. DET and Public Key Exposure		7.2. DET and Public Key Exposure
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Appendix A. Example Zone Files and RRType Contents		Appendix A. Example Zone Files and RRType Contents
	A.1. Example RAA		A.1. Example RAA
	A.1.1. Authentication HHIT		A.1.1. Authentication HHIT
	A.1.2. Delegation of HDA		A.1.2. Delegation of HDA
	skipping to change at line 158 ¶		skipping to change at line 158 ¶
	can be independent or handled by another entity as well.		can be independent or handled by another entity as well.
	1.1. General Concept		1.1. General Concept
	DRIP Entity Tags (DETs) embed a hierarchy scheme that is mapped onto		DRIP Entity Tags (DETs) embed a hierarchy scheme that is mapped onto
	the Domain Name System (DNS) [STD13]. DIMEs enforce registration and		the Domain Name System (DNS) [STD13]. DIMEs enforce registration and
	information access of data associated with a DET while also providing		information access of data associated with a DET while also providing
	the trust inherited from being a member of the hierarchy. Other		the trust inherited from being a member of the hierarchy. Other
	identifiers and their methods are out of scope for this document.		identifiers and their methods are out of scope for this document.
	Authoritative Name Servers of the DNS provide the public information		Authoritative name servers of the DNS provide the public information
	such as the cryptographic keys, endorsements and certificates of		such as the cryptographic keys, endorsements and certificates of
	DETs, and pointers to private information resources. Cryptographic		DETs, and pointers to private information resources. Cryptographic
	(public) keys are used to authenticate anything signed by a DET, such		(public) keys are used to authenticate anything signed by a DET, such
	as in the Authentication defined in [RFC9575] for Broadcast RID.		as in the Authentication Messages defined in [RFC9575] for Broadcast
	Endorsements and certificates are used to endorse the claim of being		RID. Endorsements and certificates are used to endorse the claim of
	part of the hierarchy.		being part of the hierarchy.
	This document does not specify AAA mechanisms used by Private		This document does not specify AAA mechanisms used by Private
	Information Registries to store and protect Personally Identifiable		Information Registries to store and protect Personally Identifiable
	Information (PII).		Information (PII).
	1.2. Scope		1.2. Scope
	The scope of this document is the DNS registration of DETs with the		The scope of this document is the DNS registration of DETs with the
	DNS delegation of the reverse domain of the IPv6 prefix, assigned by		DNS delegation of the reverse domain of the IPv6 prefix (2001:30::/28
	IANA for DETs 2001:30::/28 and RRsets used to handle DETs.		for DETs) and RRsets used to handle DETs.
	2. Terminology		2. Terminology
	2.1. Required Terminology		2.1. Required Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at line 204 ¶		skipping to change at line 204 ¶
	ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM.		ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM.
	From Section 2 of [RFC9434], this document uses: Certificate, DIME,		From Section 2 of [RFC9434], this document uses: Certificate, DIME,
	and Endorsement.		and Endorsement.
	From Section 2 of [RFC9374], this document uses: HDA, HID, and RAA.		From Section 2 of [RFC9374], this document uses: HDA, HID, and RAA.
	3. DET Hierarchy in DNS		3. DET Hierarchy in DNS
	[RFC9374] defines the Hierarchical Host Identity Tags (HHIT) and		[RFC9374] defines the Hierarchical Host Identity Tags (HHIT) and
	further specifies an instance of them used for UAS RID called DETs.		further specifies an instance of them used for UAS RID called DET.
	The HHIT/DET is a 128-bit value that is as an IPv6 address intended		The DET is a 128-bit value that is an IPv6 address intended primarily
	primarily as an identifier rather than locator. The format is shown		as an identifier rather than locator. The format is shown in
	in Figure 2 and further information is in [RFC9374].		Figure 2 and further information is in [RFC9374].
	+-------------+--------------+---------------+-------------+		+-------------+--------------+---------------+-------------+
	| 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) |
	+-------------+--------------+---------------+-------------+		+-------------+--------------+---------------+-------------+
	/ \		/ \
	/ \		/ \
	/ \-----------------------------\		/ \-----------------------------\
	/ \		/ \
	/ \		/ \
	skipping to change at line 365 ¶		skipping to change at line 365 ¶
	agreements, etc.) will need to be developed. These considerations		agreements, etc.) will need to be developed. These considerations
	should be determined by the CAA, perhaps in consultation with local		should be determined by the CAA, perhaps in consultation with local
	stakeholders to assess the cost-benefits of these approaches (and		stakeholders to assess the cost-benefits of these approaches (and
	others). All of these are out of scope for this document. The		others). All of these are out of scope for this document. The
	specifics for the UAS RID use case are detailed in the rest of		specifics for the UAS RID use case are detailed in the rest of
	document.		document.
	4. Public Information Registry		4. Public Information Registry
	Per [RFC9434], all information classified as public is stored in the		Per [RFC9434], all information classified as public is stored in the
	DNS, specifically Authoritative Name Servers, to satisfy REG-1 from		DNS, specifically authoritative name servers, to satisfy REG-1 from
	[RFC9153].		[RFC9153].
	Authoritative Name Servers use domain names as identifiers and data		Authoritative name servers use domain names as identifiers and data
	is stored in Resource Records (RRs) with associated RRTypes. This		is stored in Resource Records (RRs) with associated RRTypes. This
	document defines two new RRTypes, one for HHIT metadata (HHIT,		document defines two new RRTypes, one for HHIT metadata (HHIT,
	Section 5.1) and another for UAS Broadcast RID information (BRID,		Section 5.1) and another for UAS Broadcast RID information (BRID,
	Section 5.2). The former RRType is particularly important as it		Section 5.2). The former RRType is particularly important as it
	contains a URI (as part of the certificate) that points to Private		contains a URI (as part of the certificate) that points to Private
	Information resources.		Information resources.
	DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble		DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble
	reversed per Section 2.5 of RFC 3596 [STD88]) and MUST resolve to an		reversed per Section 2.5 of RFC 3596 [STD88]) and MUST resolve to an
	HHIT RRType. Depending on local circumstances or additional use		HHIT RRType. Depending on local circumstances or additional use
	skipping to change at line 415 ¶		skipping to change at line 415 ¶
	Broadcast RID information such as the Broadcast Endorsements sent as		Broadcast RID information such as the Broadcast Endorsements sent as
	described in [RFC9575].		described in [RFC9575].
	5. Resource Records		5. Resource Records
	5.1. HHIT Resource Record		5.1. HHIT Resource Record
	The HHIT Resource Record (HHIT, RRType 67) is a metadata record for		The HHIT Resource Record (HHIT, RRType 67) is a metadata record for
	various bits of HHIT-specific information that isn't available in the		various bits of HHIT-specific information that isn't available in the
	pre-existing HIP RRType. The HHIT RRType does not replace the HIP		pre-existing HIP RRType. The HHIT RRType does not replace the HIP
	RRType. The primary advantage of the HHIT RRType over the existing		RRType [RFC8005]. The primary advantage of the HHIT RRType over the
	RRType is the mandatory inclusion of the Canonical Registration		existing RRType is the mandatory inclusion of the Canonical
	Certificate containing an entity's public key signed by the		Registration Certificate containing an entity's public key signed by
	registrar, or other trust anchor, to confirm registration.		the registrar, or other trust anchor, to confirm registration.
	The data MUST be encoded in the Concise Binary Object Representation		The data MUST be encoded in the Concise Binary Object Representation
	(CBOR) [RFC8949] bytes. The Concise Data Definition Language (CDDL)		(CBOR) [RFC8949] bytes. The Concise Data Definition Language (CDDL)
	[RFC8610] of the data is provided in Figure 4.		[RFC8610] of the data is provided in Figure 4.
	5.1.1. Text Representation		5.1.1. Text Representation
	The data are represented in base64 [RFC4648] and may be divided into		The data are represented in base64 [RFC4648] and may be divided into
	any number of white-space-separated substrings, down to single base64		any number of white-space-separated substrings, down to single base64
	digits, which are concatenated to obtain the full object. These		digits, which are concatenated to obtain the full object. These
	substrings can span lines using the standard parenthesis. Note that		substrings can span lines using the standard parenthesis. Note that
	the data has internal subfields but these do not appear in the master		the data has internal subfields but these do not appear in the zone
	file representation; only a single logical base64 string will appear.		file representation; only a single logical base64 string will appear.
	5.1.1.1. Presentation Representation		5.1.1.1. Presentation Representation
	The data MAY, for display purposes only, be represented using the		The data MAY, for display purposes only, be represented using the
	Extended Diagnostic Notation as defined in Appendix G of [RFC8610].		Extended Diagnostic Notation as defined in Appendix G of [RFC8610].
	5.1.2. Field Descriptions		5.1.2. Field Descriptions
	hhit-rr = [		hhit-rr = [
	skipping to change at line 480 ¶		skipping to change at line 480 ¶
	the DET. It MUST be encoded as X.509 DER [RFC5280]. This		the DET. It MUST be encoded as X.509 DER [RFC5280]. This
	certificate MAY be self-signed when the entity is acting as a root		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		of trust (i.e., an apex). Such self-signed behavior is defined by
	policy, such as in [drip-dki], and is out of scope for this		policy, such as in [drip-dki], and is out of scope for this
	document. This certificate is part of a chain of certificates		document. This certificate is part of a chain of certificates
	that can be used to validate inclusion in the hierarchy.		that can be used to validate inclusion in the hierarchy.
	5.2. UAS Broadcast RID Resource Record		5.2. UAS Broadcast RID Resource Record
	The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format		The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format
	to hold public information typically sent over UAS Broadcast RID that		to hold information typically sent over UAS Broadcast RID that is
	is static. It can act as a data source if information is not		static. It can act as a data source if information is not received
	received over Broadcast RID or for cross validation. The primary		over Broadcast RID or for cross validation. The primary function for
	function for DRIP is to include of one or more Broadcast Endorsements		DRIP is to include of one or more Broadcast Endorsements as defined
	as defined in [RFC9575] in the auth field. These Endorsements are		in [RFC9575] in the auth field. These Endorsements are generated by
	generated by the registrar upon successful registration and broadcast		the registrar upon successful registration and broadcast by the
	by the entity.		entity.
	The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610]		The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610]
	of the data is provided in Figure 5.		of the data is provided in Figure 5.
	5.2.1. Text Representation		5.2.1. Text Representation
	The data are represented in base64 [RFC4648] and may be divided into		The data are represented in base64 [RFC4648] and may be divided into
	any number of white-space-separated substrings, down to single base64		any number of white-space-separated substrings, down to single base64
	digits, which are concatenated to obtain the full object. These		digits, which are concatenated to obtain the full object. These
	substrings can span lines using the standard parenthesis. Note that		substrings can span lines using the standard parenthesis. Note that
	the data has internal subfields but these do not appear in the master		the data has internal subfields but these do not appear in the zone
	file representation; only a single logical base64 string will appear.		file representation; only a single logical base64 string will appear.
	5.2.1.1. Presentation Representation		5.2.1.1. Presentation Representation
	The data MAY, for display purposes only, be represented using the		The data MAY, for display purposes only, be represented using the
	Extended Diagnostic Notation as defined in Appendix G of [RFC8610].		Extended Diagnostic Notation as defined in Appendix G of [RFC8610].
	All byte strings longer than a length of 20 SHOULD be displayed as		All byte strings longer than a length of 20 SHOULD be displayed as
	base64 when possible.		base64 when possible.
	5.2.2. Field Descriptions		5.2.2. Field Descriptions
	skipping to change at line 616 ¶		skipping to change at line 616 ¶
	Table 1: RAA Ranges		Table 1: RAA Ranges
	6.2.1.1. RAA Allocation Fields		6.2.1.1. RAA Allocation Fields
	Value: The RAA value delegated for this entry.		Value: The RAA value delegated for this entry.
	Name: Name of the delegated RAA. For the ISO 3166-1 Countries		Name: Name of the delegated RAA. For the ISO 3166-1 Countries
	(Section 6.2.1.4), this should be the name of the country.		(Section 6.2.1.4), this should be the name of the country.
	Policy Reference: A publicly accessible link to the requirements for		Reference: A publicly accessible link to the policy requirements for
	prospective HDA operators to register under this RAA. This field		prospective HDA operators to register under this RAA. This field
	is OPTIONAL.		is OPTIONAL.
	Contact: Contact details of the administrator of this RAA that		Contact: Contact details of the administrator of this RAA that
	prospective HDA operators can make informational queries to.		prospective HDA operators can make informational queries to.
	6.2.1.2. RAA Registration Form		6.2.1.2. RAA Registration Form
	Value:		Value:
	Name:		Name:
	Policy Reference:		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):
	Figure 6: RAA Delegation Request Form		Figure 6: RAA Delegation Request Form
	The NS RRType Content (HDA=X) fields are used by IANA to perform the		The NS RRType Content (HDA=X) fields are used by IANA to perform the
	DNS delegations under 3.0.0.1.0.0.2.ip6.arpa.. See Section 6.2.1.3		DNS delegations under 3.0.0.1.0.0.2.ip6.arpa.. See Section 6.2.1.3
	skipping to change at line 669 ¶		skipping to change at line 669 ¶
	6.2.1.4. ISO 3166-1 Countries Range		6.2.1.4. ISO 3166-1 Countries Range
	The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is		The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is
	specified and documented by IANA. Each Nation is assigned 4 RAAs		specified and documented by IANA. Each Nation is assigned 4 RAAs
	that are left to the national authority for their purpose. For RAAs		that are left to the national authority for their purpose. For RAAs
	under this range, a shorter prefix of 2001:3x:xx00::/40 MAY be		under this range, a shorter prefix of 2001:3x:xx00::/40 MAY be
	delegated to each CAA, which covers all 4 RAAs (and reserved HDAs)		delegated to each CAA, which covers all 4 RAAs (and reserved HDAs)
	assigned to them.		assigned to them.
	This range is set to IESG Approval (Section 4.10 of [RFC8126]) and		The registration policy for this range is set to IESG Approval
	IANA will liaise with the ICAO to verify the authenticity of		(Section 4.10 of [RFC8126]) and IANA will liaise with the ICAO to
	delegation requests (using Figure 6) by CAAs.		verify the authenticity of delegation requests (using Figure 6) by
			CAAs.
	6.2.1.5. Private Range		6.2.1.5. Private Range
	If nibble-reversed lookup in DNS is desired, it can only be provided		If nibble-reversed lookup in DNS is desired, it can only be provided
	by private DNS servers as zone delegations from the global root will		by private DNS servers as zone delegations from the global root will
	not be performed for this address range. Thus the RAAs (with its		not be performed for this address range. Thus the RAAs (with its
	subordinate HDAs) in this range may be used in like manner and IANA		subordinate HDAs) in this range may be used in like manner and IANA
	will not delegate any value in this range to any party (as per		will not delegate any value in this range to any party (as per
	Private Use, Section 4.1 of [RFC8126]).		Private Use, Section 4.1 of [RFC8126]).
	One anticipated acceptable use of the private range is for		One anticipated acceptable use of the private range is for
	experimentation and testing prior to request allocation or assignment		experimentation and testing prior to request allocation or assignment
	from IANA.		from IANA.
	6.2.2. HHIT Entity Type		6.2.2. HHIT Entity Types
	This document requests a new registry for HHIT Entity Type under the		This document requests a new registry for HHIT Entity Types under the
	"Drone Remote ID Protocol" registry group		"Drone Remote ID Protocol" registry group
	<https://www.iana.org/assignments/drip>.		<https://www.iana.org/assignments/drip>.
	HHIT Entity Type: Numeric, field of the HHIT RRType to encode the		HHIT Entity Type: Numeric, field of the HHIT RRType to encode the
	HHIT Entity Type. All entries in this registry are under the		HHIT Entity Type. All entries in this registry are under the
	First Come First Served policy (Section 4.4 of [RFC8126]).		First Come First Served policy (Section 4.4 of [RFC8126]).
	6.2.2.1. HHIT Type Registry Fields		6.2.2.1. HHIT Type Registry Fields
	Value: HHIT Type value of the entry.		Value: HHIT Type value of the entry.
	skipping to change at line 763 ¶		skipping to change at line 764 ¶
	| 27 | Crowd Sourced RID Finder | RFC 9886 |		| 27 | Crowd Sourced RID Finder | RFC 9886 |
	+-------+-------------------------------------------+-----------+		+-------+-------------------------------------------+-----------+
	Table 2: HHIT Entity Type Initial Values		Table 2: HHIT Entity Type Initial Values
	7. Security Considerations		7. Security Considerations
	7.1. DNS Operational and Registration Considerations		7.1. DNS Operational and Registration Considerations
	The Registrar and Registry are commonly used concepts in the DNS.		The Registrar and Registry are commonly used concepts in the DNS.
	These components interface the DIME into the DNS hierarchy and thus		These components connect the DIME with the DNS hierarchy and thus
	operation SHOULD follow best common practices, specifically in		operation SHOULD follow best common practices, specifically in
	security (such as running DNSSEC) as appropriate except when national		security (such as running DNSSEC) as appropriate except when national
	regulations prevent it. [BCP237] provides suitable guidance.		regulations prevent it. [BCP237] provides suitable guidance.
	If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed		If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed
	and published. It SHOULD explain how DNSSEC has been deployed and		and published. It SHOULD explain how DNSSEC has been deployed and
	what security measures are in place. [RFC6841] documents a framework		what security measures are in place. [RFC6841] documents a framework
	for DNSSEC policies and DNSSEC Practice Statements. A self-signed		for DNSSEC policies and DNSSEC Practice Statements. A self-signed
	entity (i.e., an entity that self-signed its certificate as part of		entity (i.e., an entity that self-signed its certificate as part of
	the HHIT RRType) MUST use DNSSEC.		the HHIT RRType) MUST use DNSSEC.
	skipping to change at line 852 ¶		skipping to change at line 853 ¶
	8.1. Normative References		8.1. Normative References
	[F3411] ASTM International, "Standard Specification for Remote ID		[F3411] ASTM International, "Standard Specification for Remote ID
	and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July		and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
	2022, <https://www.astm.org/f3411-22a.html>.		2022, <https://www.astm.org/f3411-22a.html>.
	[ISO3166-1]		[ISO3166-1]
	ISO, "Codes for the representation of names of countries		ISO, "Codes for the representation of names of countries
	and their subdivisions - Part 1: Country code",		and their subdivisions - Part 1: Country code",
	ISO 3166-1:2020, August 2020,		ISO 3166-1:2020, August 2020,
	<https://www.iso.org/iso-3166-country-codes.html>.		<https://www.iso.org/standard/72482.html>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	skipping to change at line 904 ¶		skipping to change at line 905 ¶
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A		[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
	Framework for DNSSEC Policies and DNSSEC Practice		Framework for DNSSEC Policies and DNSSEC Practice
	Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,		Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
	<https://www.rfc-editor.org/info/rfc6841>.		<https://www.rfc-editor.org/info/rfc6841>.
			[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
			System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
			October 2016, <https://www.rfc-editor.org/info/rfc8005>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	skipping to change at line 1455 ¶		skipping to change at line 1460 ¶
	}		}
	Figure 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID		Figure 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID
	RRType CBOR		RRType CBOR
	Acknowledgements		Acknowledgements
	Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT		Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT
	Consulting, LLC) for their early work on the DRIP registries concept.		Consulting, LLC) for their early work on the DRIP registries concept.
	Their early contributions laid the foundation for the content and		Their early contributions laid the foundation for the content and
	processes of this architecture and document.		processes of this architecture and document. The authors would also
			like to thank the DRIP chairs and AD, the reviewers from the various
			Directorates, and the members of the IESG at time of publication.
	Authors' Addresses		Authors' Addresses
	Adam Wiethuechter (editor)		Adam Wiethuechter (editor)
	AX Enterprize, LLC		AX Enterprize, LLC
	4947 Commercial Drive		4947 Commercial Drive
	Yorkville, NY 13495		Yorkville, NY 13495
	United States of America		United States of America
	Email: adam.wiethuechter@axenterprize.com		Email: adam.wiethuechter@axenterprize.com
End of changes. 20 change blocks.
	36 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.48.