> 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-numbers
> 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.
>> 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.
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
