[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
- [DNSOP] IPN and CLA RRTYPEs to support Bundle Pro… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… sburleig.sb
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Erik Kline
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: [EXT] Re: Re: IPN and CLA R… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Adam Wiethuechter
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYP… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Marc Blanchet
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYP… Sipos, Brian J.
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Mark Andrews
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Paul Vixie
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … sburleig.sb
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Sauli Kiviranta
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Joe Abley
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Alberto Montilla (SPATIAM)
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Mark Andrews
- [DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and… Jorge Amodio
- [DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [EXT] [dtn] Re: RE: Re: IPN and CLA R… Sipos, Brian J.
- [DNSOP] Re: [EXT] [dtn] Re: RE: Re: IPN and CLA R… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Scott Johnson
- [DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYP… Marc Blanchet
- [DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and… Scott Johnson
- [DNSOP] Re: [dtn] Re: [EXT] Re: RE: Re: IPN and C… Sauli Kiviranta
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor