Speaking as the responsible AD for DTN, I think the DTN working group should probably have a discussion about what it wants to do (if anything) vis. DNS RRs.
On Tue, Jun 25, 2024 at 08:27 Scott Johnson <sc...@spacelypackets.com> wrote: > Hi Mark, > > On Tue, 25 Jun 2024, Mark Andrews wrote: > > > > > > >> 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. > > (05) of the draft adds a "Contributors" section. > > > > >> 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. > > Ack. Thank you so much for your time and attention to this document. > > ScottJ > > > > >> 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 sen > <https://www.google.com/maps/search/to+clarify+the+requests,+and+that+said+i-d+be+sen?entry=gmail&source=g>t > 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 > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
