I've lost lock on the ipn-scheme RFC, but my own assessment is that always sending a single 64-bit unsigned integer would be fine. The application receiving the resource can figure out whether or not it wants to condense the value by representing it as two 32-bit integers in ASCII with leading zeroes suppressed and a period between the two. Internally it's always going to be a 64-bitunsigned integer, from which a 32-bit "allocator" number can be obtained by simply shifting 32 bits to the right; if the result is zero then we're looking at an old-style IPN node number.
Scott -----Original Message----- From: Scott Johnson <sc...@spacelypackets.com> Sent: Monday, June 24, 2024 8:26 PM To: Mark Andrews <ma...@isc.org>; sburleig...@gmail.com Cc: dnsop <dnsop@ietf.org> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support Bundle Protocol RFC9171 Hi Mark, On Tue, 25 Jun 2024, Mark Andrews wrote: > > >> On 25 Jun 2024, at 10:32, Scott Johnson <sc...@spacelypackets.com> wrote: >> >> Hi Mark, >> >> On Tue, 25 Jun 2024, Mark Andrews wrote: >> >>> An obvious correction “LTP--v6” -> “LTP-v6” >> >> Aha! Good eye. >> >>> >>> For IPN why isn’t the wire format two network 64 bit integers? That is 16 >>> bytes. Also 2^64-1 is 20 characters so 2 64-bit numbers separated by “." >>> is 41 characters. It’s not clear where then 21 comes from. >> >> EID is the basic unit of IPN naming, which is indeed two 64 bit integers >> separated by a ".". We are seeking to represent only the node-nbr component >> of an EID, as the service-nbr component is loosely analagous to a UDP or TCP >> port, for which there is one publicly defined service in the registry, and a >> collection of space agencies who lay claim to another chunk of them: >> https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-num >> bers As such, there is no gain in including the second 64-bit >> integer, representing service-nbr in the DNS records, and indeed, a loss of >> utility on the application level. >> >> The node-nbr component is presently, under RFC7116, a 64 bit unsigned >> integer. There is a draft from the DTN WG currently making it's way through >> the IESG which will amend the IPN naming scheme. Perhaps I should add it to >> normative references? >> https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ >> >> In effect it splits the node-nbr component into two-32 bit integers; >> Allocator Identifier and Node Number in the "Three-Element Scheme-Specific >> Encoding" of Section 6.1.2 over the above. Section 6.1.1 describes the >> "Two-Element Scheme-Specific Encoding" method which retains the use of a >> single 64-bit integer. Thus, a single 64 bit integer (20 characters) or two >> 32-bit integers (10 characters each) delimited by a "." >> makes 21 characters maximum. This preserves forwards compatibility with the >> proposed amended scheme, and does no harm if the scheme fails to achieve >> standardization. > > Or just 8 bytes on the wire with both possible input formats described. > Machines using the records will just be converting ASCII values to a > 64 bit integer. We may as well transmit it as that. Input validation > will need to do the conversion anyway to ensure both fields will fit > into 32 bits in the “.” separated case and 64 bits in the single value case. > Length along is not sufficient to prevent undetected overflows. The > only thing you need to determine is which format is the initial > canonical presentation format. That can be changed with a later > update if needed. I am tagging in Scott Burleigh, co-author of RFC9171 on this point for clarification. Section 4.2.5.1.2 of same indicates: "Encoding considerations: For transmission as a BP endpoint ID, the scheme-specific part of a URI of the ipn scheme SHALL be represented as a CBOR array comprising two items. The first item of this array SHALL be the EID's node number (a number that identifies the node) represented as a CBOR unsigned integer. The second item of this array SHALL be the EID's service number (a number that identifies some application service) represented as a CBOR unsigned integer. For all other purposes, URIs of the ipn scheme are encoded exclusively in US-ASCII characters." Having already established that we are transmitting the node-nbr component only, and not a full EID, I am not sure we are restricted to using only US-ASCII. ScottB, your opinion? CBOR might also be an option, but that would place a higher burden upon implementers, I think. Integer notation for wire format is fine by me. > >>> Limit CLA characters to Letter Digit Hyphen rather than the full ASCII >>> range. >> >> It is possible for a node to support multiple CLAs on the same IP >> address and node number. Will this change allow multiple, comma >> delimited values to be expressed in the CLA record? If so, can you >> point me to an example so I can get the verbiage of the draft right? >> If not, what do you recommend (in addition to my defining that in the >> draft)? I like the idea of limiting the usable characters. > > Personally I would just use a TXT record wire format with the > additional constraint that the values are restricted to Letter, Digits > and interior Hyphens. The input format matches the TXT record with > the above character value constraints. The canonical presentation > form is space separated, unquoted, unescaped ASCII. This allow for > long records to be split over multiple lines. Descriptive comments in the > zone file. > This take one extra octet over using comma separated values. Sold to the man from ISC :) This part works great; thank you! Updated draft pushed to datatracker at https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ Thanks, Scott > > e.g. > > example inputs > > @ CLA ( TCP-V4 ; TCP over IPv4 > TCP-V6 ) ; TCP over IPv6 > > @ CLA “TCP-V4” TCP-V6 > > Wire > > 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘6’ > > Canonical presentation > > @ CLA TCP-V4 TCP-V6 > > >> Thanks, >> Scott >> >>> >>> Mark >>> >>>> On 25 Jun 2024, at 08:19, Scott Johnson <sc...@spacelypackets.com> wrote: >>>> >>>> Hi All, >>>> >>>> After reading the recent discussion about WALLET, I am hesitant to jump >>>> into the fray here, but this plainly is the correct group to help me get >>>> my logic and syntax right, so here goes: >>>> >>>> I submitted requests to IANA for IPN and CLA RRTYPEs, these representing >>>> the missing datasets necessary to make a BP overlay network connection >>>> from data found by DNS queries. >>>> >>>> For those not familiar, BP is a store and forward mechanism generally used >>>> in high latency situations where there does not exist constant end-to-end >>>> connectivity. It was designed for deep space networking, however has >>>> network segments and application uses which overlay the terrestrial >>>> Internet. There will arise similar use cases on the Moon (in the >>>> reasonably near future) and Mars whereby low latency, constant >>>> connectivity exists, thereby making use of DNS in these situations viable. >>>> >>>> My Expert Reviewer asked for an i-d, to clarify the requests, and that >>>> said i-d be sent to this list for review. >>>> >>>> Please find the approptiate draft here: >>>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ >>>> >>>> Relevant IANA requests: >>>> https://tools.iana.org/public-view/viewticket/1364843 >>>> https://tools.iana.org/public-view/viewticket/1364844 >>>> >>>> I have the BP community also reviewing this, but they are generally in >>>> agreement as to use. >>>> >>>> Thanks, >>>> Scott M. Johnson >>>> Spacely Packets, LLC >>>> >>>> _______________________________________________ >>>> DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email >>>> to dnsop-le...@ietf.org >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> _______________________________________________ >>> DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to >>> dnsop-le...@ietf.org > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
