> On 25 Jun 2024, at 16:36, Scott Johnson <sc...@spacelypackets.com> wrote: > > Hi Mark, > > Noted and changed. Good stuff, thanks. Updated draft (04) at datatracker > using that verbiage: > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > Is it appropriate to add an acknowledgments section or co-authors at this > point?
I’m not fussed either way. > As well, should I be asking for WG adoption (DNSOP or DTN WG), or as an > Informational document, is Individual submission sufficient? I’ll leave that for the chairs to answer. > Thanks, > ScottJ > > > On Tue, 25 Jun 2024, Mark Andrews wrote: > >> Made the IPN description more specific. >> >> >> Wire format encoding shall >> be an unsigned 64-bit integer in network order. Presentation format, for >> these >> resource records are either a 64 bit unsigned decimal integer, or two 32 bit >> unsigned decimal integers delimited by a period with the most significant 32 >> bits >> first and least significant 32 bits last. Values are not to be zero padded. >> >>> On 25 Jun 2024, at 15:22, Scott Johnson <sc...@spacelypackets.com> wrote: >>> >>> Hi Scott, >>> >>> Wire format of 64 bit unsigned integer it is for IPN. >>> Updated draft (03) incorporating all changes posted at: >>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ >>> >>> Let me know if you see anything else, Mark, and thanks! >>> >>> >>> ScottJ >>> >>> >>> On Mon, 24 Jun 2024, sburleig...@gmail.com wrote: >>> >>>> 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 >> >> >> -- >> 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
