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