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
