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

Rick Taylor <rick@tropicalstormsoftware.com> Wed, 26 June 2024 20:40 UTC

Return-Path: <rick@tropicalstormsoftware.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4CCC15107E; Wed, 26 Jun 2024 13:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2vC-kzVoT91; Wed, 26 Jun 2024 13:40:22 -0700 (PDT)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA45C14F711; Wed, 26 Jun 2024 13:40:19 -0700 (PDT)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi id 14.03.0513.000; Wed, 26 Jun 2024 21:40:16 +0100
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: Scott Johnson <scott@spacelypackets.com>
Thread-Topic: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Thread-Index: AQHaxuZcrBpXITrSgEOA4r2O6QrwrLHYa3XQgADCNICAAESdgIAAzvAAgAAwH4CAABJFsA==
Date: Wed, 26 Jun 2024 20:40:15 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F98027373928B@tss-server1.home.tropicalstormsoftware.com>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <b3f42856-9460-2fa2-1088-185fda441f51@spacelypackets.com> <F2BD591F-8512-4E3E-ABA2-3DF3F34372CB@isc.org> <16835c41-0e6c-bde4-d197-847928171e55@spacelypackets.com> <047a01dac6b8$43d70ca0$cb8525e0$@gmail.com> <57ca71b8-aa29-8a07-5154-e6b9c44bc64a@spacelypackets.com> <AC5B89B2-DD53-4A36-9B87-4136EC288851@isc.org> <2dec1732-841e-dd38-85a8-3263b1c59885@spacelypackets.com> <C363E260-22EA-43E9-97B6-D7A403C205ED@isc.org> <98976a58-b976-e82c-4b12-76edce92e691@spacelypackets.com> <CAMGpriUVcoJu1CWWLapwREN2NaHJFnVkGUpF45TJotm7uyAxyg@mail.gmail.com> <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273735D06@tss-server1.home.tropicalstormsoftware.com> <b3ee82da-ae38-5781-77eb-bab292d5c113@spacelypackets.com> <cca98f92-27ee-d372-b419-81c63777033b@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com> <24b5ed89-c7fa-8d2d-826b-f8e08779b6d8@spacelypackets.com>
In-Reply-To: <24b5ed89-c7fa-8d2d-826b-f8e08779b6d8@spacelypackets.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: YMONYTTSRDR3QJDBPOD2DZBMPMFUBTHL
X-Message-ID-Hash: YMONYTTSRDR3QJDBPOD2DZBMPMFUBTHL
X-MailFrom: rick@tropicalstormsoftware.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JimEG-4Kfq2mC5HfI0jI_3nzyoI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Scott,

I would ask one change please.  The wire format for ipn EID is well documented in RFC9171, and updated in the forthcoming ipn-update.  Please can you use the CBOR encoding?

As an a side, could you describe the needs of your application, I didn't quite understand your HTTP request analogy, as that is a early-bind usage, and BP is built on the concept of late-binding.

Cheers,
Rick

> -----Original Message-----
> From: Scott Johnson [mailto:scott@spacelypackets.com]
> Sent: 26 June 2024 21:32
> To: Rick Taylor
> Cc: Erik Kline; dnsop; sburleig.sb@gmail.com; dtn@ietf.org
> Subject: Re: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> Protocol RFC9171
> 
> Hi Rick,
> 
> On Wed, 26 Jun 2024, Rick Taylor wrote:
> 
> > Hi Scott,
> >
> > Thanks for the updated doc.  I've been thinking through what I
> > understand is your use-case, and I wonder whether new RRTYPEs is really
> > the right way to go.  As I see it, the less one has to update the DNS
> > infrastructure of the Internet the better,
> 
> I disagree with this assessment.  RFC 6895 clearly lays out a policy for
> the allocation of RRTYPEs that encourages the creation of same.  I have
> followed that policy to the letter, and produced all the necessary
> documentation, including this draft which was forwarded to this WG as a
> courtesy to the Transport AD.  This is the cleanest and shortest path
> forward to achieve the functionality I am looking for.  Recently, a WALLET
> RRTYPE was created to store crytocurrency wallet addresses.  It did not
> require an RFC or even an i-d, much less wg adoption or discussion.
> 
> The topic of this draft is wire and presentation encoding of two RRTYPEs,
> and as such, discussion should be limited to that.  It has already been
> established that nothing in my RRTYPE requests nor draft will interfere
> with any present DTN related drafts or standards.  If you don't like my
> proposal, simply do not use it in your networks, but please do not try to
> derail what I have already set in motion outside the perview of this WG if
> it does not meet _your_ needs, as it does meet mine.  Again, one may
> assign IPv6 addresses by means of DHCPv6, SLAAC, or manual assignment.
> This is no different.
> 
> Any such 'update to the DNS infrastructure' would happen by DNS
> implementers, as part of the normal update and release schedule.  It is
> notable that Mark Andrews from ISC, the organization responsible for
> maintaining BIND, contributed to the technical verbiage of this draft
> describing wire and presentation types for the RRTYPEs which have been
> requested.  I followed his recommendations as to encoding, which
> presumably will make implementation work easier, as well as saving a few
> bytes over textual encoding, which is only required for representations
> of EID per RFC9171.
> 
> > so would this alternative
> > mechanism work for you?:
> 
> No.  I do feel that reverse DNS records for BP identifiers is a
> useful pursuit, but is not critical to my application, and out of scope
> as relates to the draft being discussed.
> 
> > The IETF creates a subdomain of `ipn.arpa.` under which all ipn FQNNs in
> > text format (reversed) may be registered, much like public IP addresses
> > under `inet.arpa.`, e.g. ipn:1.2.x would be registered as
> > `2.1.ipn.arpa.`.  This would allow any DNS capable host to resolve an
> > ipn FQNN to DNS name.
> 
> This will require a time consuming standards action from a work group
> which, with all due respect, is well behind on milestones already. It will
> simply take too long.  It has already taken more man hours defending the
> creation of these RRTYPEs (which is not part of the defined process) than
> it took to perfect their additional documentation with DNSOP.  The policy
> governing RRTYPEs is deliberately liberal, to encourage fast innovation,
> and this is, IMHO, the best way to expeditiously move forward, which is
> what is required at this time.
> 
> >
> > Under this DNS name, one could have one or more regular SRV records of
> > the form "_service._protocol.name", e.g.
> > "_tcpcl._tcp.spacelypackets.com." that would allow an entity to discover
> > that TCPCL is available, and of course "spacelypackets.com." (more
> > correctly the target of the SRV record) can be resolved quite normally
> > via an A or AAAA record to your BPA's IP address.
> 
> I will note that I was personally admonished by the now former Transport
> AD for using "real company names" when making an example on the DTN
> mailing list.
> 
> >
> > Of course one can sprinkle PTR and CNAME records throughout to add
> > indirection and delegate authority, perhaps to ipn Allocators.  Also the
> > "ipn.arpa." registration can be skipped altogether, and instead DNS-SD
> > or DHCP/RA options can be used to discover the corresponding SRV record
> > entries without requiring global registration.
> 
> Sorry.  I prefer dedicated records, which is what I have requested from
> IANA.  Please feel free to develop whatever solution best meets your
> needs.
> 
> >
> > This has the following advantages as I see it:
> > 1. An ipn EID is now mapped to a Name that can be asserted using regular
> DNS-name based certificate services.
> 
> My RRTYPE requests and subsequent draft do not address EIDs, and hence,
> are seeking to achieve something different than your proposal.
> 
> 
> > 2. Existing DNS software does not need to be updated.  I can configure my
> ancient BSD box with BIND to do this now.
> 
> If you keep your copy of BIND updated regularly, then you will notice no
> difference when the new RRTYPEs are supported.  If you don't keep it
> updated, you do so at your own risk, as security fixes are pushed as
> necessary with regular updates.
> 
> > 3. We don't need yet another binary encoding of ipn EIDs, it's just text.
> 
> There is no "new" binary encoding of EIDs; indeed, EID's are not treated
> in my draft.  Textual encoding for the (node-nbr) component was my
> original plan, however, but it was pointed out that this would be
> converted to a 64-bit inside the nameserver anyway, so we might as well
> transmit it as such, and save 13 bytes on the wire.
> 
> >
> > However, I may have misunderstood your use-case, so this might not be
> > viable alternative.
> >
> > Thoughts?
> 
> Per 'Note Well', I do not wish to further discuss my use case at this
> time, but suffice it to say that those resources which I have requested to
> be created by the proper procedure and in the proper venue are sufficient
> to meet the needs of my use case, while proffered alternatives do not.
> I feel that alternative efforts are worthwhile, and encourage their
> further development and standardization.  I see no conflict between any
> proposed methods and those requests which I have made.  Provision was
> made
> to support the draft you currently have under IESG review, such that, in
> the event that it becomes RFC, no change will have to be made to the
> RRTYPE.  I see no legitimate reason, nor standing, per the agreed upon
> procedure, to oppose the creation of these RRTYPEs.
> 
> ScottJ
> 
> >
> > Rick
> >
> > P.S. I'm sure Brian Sipos has a more flexible solution using his EID Patterns
> under the `ipn.arpa` TLD, but I don't want to muddy the waters by trying to
> introduce it now
> >
> >
> >> -----Original Message-----
> >> From: Scott Johnson [mailto:scott@spacelypackets.com]
> >> Sent: 26 June 2024 06:19
> >> To: Rick Taylor
> >> Cc: Erik Kline; dnsop; sburleig.sb@gmail.com; dtn@ietf.org
> >> Subject: Re: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> >> Protocol RFC9171
> >>
> >> Hi All,
> >>
> >> A new version of this draft (06) has been posted here:
> >> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
> >>
> >> This includes edits from Scott Burleigh, as well as edits based on the
> >> feedback from Brian and Rick, but for the references to specs for existing
> >> CLAs in use in the wild.
> >>
> >> Happy to hear any further comments.
> >>
> >> Thanks,
> >> ScottJ
> >>
> >>
> >> On Wed, 26 Jun 2024, Scott Johnson wrote:
> >>
> >>> Hi Rick,
> >>>
> >>> On Tue, 25 Jun 2024, Rick Taylor wrote:
> >>>
> >>>> Hi Scott,
> >>>>
> >>>> Thanks for publishing this doc, it looks really interesting.
> >>>
> >>> You are welcome.  Thanks for taking the time to review.
> >>>
> >>>>
> >>>> One thing I am unclear about is what is the purpose of having a DNS
> >>>> record mapping a dtn or ipn Node ID to an IP address.
> >>>
> >>> That is not exactly what is happening.  I am mapping an IPN node number
> >>> to
> >>> domain name.  That domain name may or may not have IPv4 or IPv6
> >>> addresses also mapped to it, but that is irrelevant.
> >>>
> >>>> Is it so that 'routing' lookups can be performed at BPAs when a next
> >>>> hop for a particular EID is not known locally?
> >>>
> >>> That is an interesting concept perhaps worth exploring further, but no,
> >>> that was not my intention.
> >>>
> >>>> It would be great to have the rationale described in the document.
> >>>
> >>> Sure, but the whole thing might be out of scope for DTN WG; it addresses
> >>> application layer (outside the BPA) considerations.
> >>>
> >>> Consider that what BP excels at in robustness and extensibility, it
> >>> lacks in standardized applications.  One barrier to BP native
> >>> application authoring which has been identified is lack of an API.  This
> >>> is being explored in multiple directions, including userspace and kernel
> >>> API implementations. It is highly useful, when operating over the
> >>> underlying Internet, for an application to be able to collect all
> >>> necessary connectivity data via DNS query.
> >>>
> >>> A web browser, for example, does a DNS lookup before making a http
> >>> request.  At a minimum, this means Node Number and available CLA(s) in
> >>> addition to IP address when making a BP connection.  If BPSEC is
> >>> deployed, additional RRTYPES, such as a security context identifier
> >>> (CTX?) and public key (BSEC?) records might be appropriate to negotiate
> >>> such a connection, but they are out of scope for this draft.
> >>>
> >>> If the application then transmits that information via an API to the
> >>> BPA, the BPA can take action in the contact graph to perfect the
> >>> connection. This draft, and the RRTYPEs it describes, enable a preferred
> >>> component of an API structure to encourage application development.
> >>>
> >>>>
> >>>> I'm also a wondering if there out to be references to the relevant
> >>>> specifications for the CLA's in the RRTPE values: e.g. BSSP-v6 and
> >>>> STCP-v4?
> >>>
> >>> Sure, that would be great.  I am not aware of specification documents
> >>> for many of these, and for IPND (which I know is not a CLA, but provides
> >>> a useful discrete automated Node Number and CLA signaling system)
> there
> >>> is only the expired draft I posted last year.  What I do have for all of
> >>> them is running code.  I will dig about a bit for (perhaps archival)
> >>> spec documents on the other listed CLAs.
> >>>
> >>> Thanks,
> >>> Scott
> >>>
> >>>>
> >>>> Cheers,
> >>>> Rick
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Scott Johnson [mailto:scott@spacelypackets.com]
> >>>>> Sent: 25 June 2024 10:57
> >>>>> To: Erik Kline
> >>>>> Cc: dnsop; sburleig.sb@gmail.com; dtn@ietf.org
> >>>>> Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> >>>>> Protocol RFC9171
> >>>>>
> >>>>> 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
> >>>>>> <scott@spacelypackets.com>
> >>>>>> wrote:
> >>>>>>       Hi Mark,
> >>>>>>
> >>>>>>       On Tue, 25 Jun 2024, Mark Andrews wrote:
> >>>>>>
> >>>>>>     >
> >>>>>>     >
> >>>>>>     >> On 25 Jun 2024, at 16:36, Scott Johnson
> >>>>>>       <scott@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
> >>>>>>       <scott@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.sb@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 <scott@spacelypackets.com>
> >>>>>>     >>>>> Sent: Monday, June 24, 2024 8:26 PM
> >>>>>>     >>>>> To: Mark Andrews <marka@isc.org>;
> >>>>>>       sburleig.sb@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
> >>>>>>       <scott@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
> >>>>>>       <scott@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-leave@ietf.org
> >>>>>>     >>>>>>>>
> >>>>>>     >>>>>>>> --
> >>>>>>     >>>>>>>> Mark Andrews, ISC
> >>>>>>     >>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>     >>>>>>>> PHONE: +61 2 9871 4742              INTERNET:
> >>>>>>       marka@isc.org
> >>>>>>     >>>>>>>>
> >>>>>>     >>>>>>>> _______________________________________________
> >>>>>>     >>>>>>>> DNSOP mailing list -- dnsop@ietf.org To
> >>>>>>       unsubscribe send an email to
> >>>>>>     >>>>>>>> dnsop-leave@ietf.org
> >>>>>>     >>>>>>
> >>>>>>     >>>>>>
> >>>>>>     >>>>>> --
> >>>>>>     >>>>>> Mark Andrews, ISC
> >>>>>>     >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>     >>>>>> PHONE: +61 2 9871 4742              INTERNET:
> >>>>>>       marka@isc.org
> >>>>>>     >>>>>>
> >>>>>>     >>>>>>
> >>>>>>     >>>>>
> >>>>>>     >>>>> _______________________________________________
> >>>>>>     >>>>> DNSOP mailing list -- dnsop@ietf.org
> >>>>>>     >>>>> To unsubscribe send an email to dnsop-leave@ietf.org
> >>>>>>     >>>
> >>>>>>     >>>
> >>>>>>     >>> --
> >>>>>>     >>> Mark Andrews, ISC
> >>>>>>     >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>     >>> PHONE: +61 2 9871 4742              INTERNET:
> >>>>>>       marka@isc.org
> >>>>>>     >>>
> >>>>>>     >>> _______________________________________________
> >>>>>>     >>> DNSOP mailing list -- dnsop@ietf.org
> >>>>>>     >>> To unsubscribe send an email to dnsop-leave@ietf.org
> >>>>>>     >
> >>>>>>     >
> >>>>>>     > --
> >>>>>>     > Mark Andrews, ISC
> >>>>>>     > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>     > PHONE: +61 2 9871 4742              INTERNET:
> >>>>>>       marka@isc.org
> >>>>>>     >
> >>>>>>     > _______________________________________________
> >>>>>>     > DNSOP mailing list -- dnsop@ietf.org
> >>>>>>     > To unsubscribe send an email to
> >>>>>>       dnsop-
> >>>>> leave@ietf.org_______________________________________________
> >>>>>>       DNSOP mailing list -- dnsop@ietf.org
> >>>>>>       To unsubscribe send an email to dnsop-leave@ietf.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> > _______________________________________________
> > dtn mailing list -- dtn@ietf.org
> > To unsubscribe send an email to dtn-leave@ietf.org