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

[Scott Johnson <[e-mail]>]

Hi Erik,

Cross posted to DTN list for any such discussion, if they so desire.
The draft in question is here:
https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/

Thanks,
ScottJ

On Tue, 25 Jun 2024, Erik Kline wrote:

> 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 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 -- [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]
> 
> 
>