[DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

[Erik Kline <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Mark,
>
> On Tue, 25 Jun 2024, Mark Andrews wrote:
>
> >
> >
> >> On 25 Jun 2024, at 16:36, Scott Johnson <[e-mail]>
> 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 <[e-mail]>
> 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, [e-mail] 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 <[e-mail]>
> >>>>> Sent: Monday, June 24, 2024 8:26 PM
> >>>>> To: Mark Andrews <[e-mail]>; [e-mail]
> >>>>> Cc: dnsop <[e-mail]>
> >>>>> 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 <[e-mail]>
> 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 <
> [e-mail]> 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 -- [e-mail] To unsubscribe send an
> email
> >>>>>>>>> to [e-mail]
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Mark Andrews, ISC
> >>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>>> PHONE: [phone]              INTERNET: [e-mail]
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> DNSOP mailing list -- [e-mail] To unsubscribe send an
> email to
> >>>>>>>> [e-mail]
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Mark Andrews, ISC
> >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>> PHONE: [phone]              INTERNET: [e-mail]
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> DNSOP mailing list -- [e-mail]
> >>>>> To unsubscribe send an email to [e-mail]
> >>>
> >>>
> >>> --
> >>> Mark Andrews, ISC
> >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>> PHONE: [phone]              INTERNET: [e-mail]
> >>>
> >>> _______________________________________________
> >>> DNSOP mailing list -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]              INTERNET: [e-mail]
> >
> > _______________________________________________
> > DNSOP mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>