A. Submission Date: May 7th, 2024

B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE
B.2 Kind of RR: [X] Data RR [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
Name: Scott M. Johnson Email Address: scott&spacelypackets.com
International telephone number: +13868887311
Other contact handles:

D. Motivation for the new RRTYPE application.

Bundle Protocol (RFC 9171), specifies the "ipn" URI scheme
(section 4.2.5.1.2) for use in naming nodes in Delay and
Disruption Tolerant Networks (DTNs). This URI scheme is widely
deployed among DTNs, and would benefit from having the capability
to look up the CBHE Node Number (node-nbr) component (or successor
standard) for a given node based on a domain name.

https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-node-numbers

E. Description of the proposed RR type.

A record using the proposed RRTYPE would consist of one 64 bit
integer, representing the CBHE Node Number component of the "ipn"
URI of a given DTN node (RFC 7116), encoded in US-ASCII. Future
amendments to the "ipn" URI scheme may modify the Node Number data
structure, but given that the RRTYPE is to be processed as an
"unknown RRTYPE" these amendments will be irrelevant to nameserver
operation.

F. What existing RRTYPE or RRTYPEs come closest to filling that need
and why are they unsatisfactory?

There are many RRTYPES which are similar and complementary in
function to the proposed new RRTYPE, such as A, AAAA, X25 or ISDN.
These are unsatisfactory due to incompatible data structures and
the desire for disambiguity in the use of a particular RRTYPE.

G. What mnemonic is requested for the new RRTYPE (optional)?

IPN

H. Does the requested RRTYPE make use of any existing IANA registry
or require the creation of a new IANA subregistry in DNS
Parameters?

Other than the addition of the IPN RRTYPE to the existing
"Resource Record (RR) TYPEs" IANA Registry, no modifications
are required.

I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed
as an unknown RRTYPE (see [RFC3597])?

No.

J. Comments: