[DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Rick Taylor <rick@tropicalstormsoftware.com> Fri, 28 June 2024 12:29 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 A7944C14F749; Fri, 28 Jun 2024 05:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 bg2KnzOz_4u7; Fri, 28 Jun 2024 05:29:18 -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 E6C48C14F748; Fri, 28 Jun 2024 05:29:16 -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; Fri, 28 Jun 2024 13:29:13 +0100
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: Jorge Amodio <jmamodio@gmail.com>, Scott Johnson <scott@spacelypackets.com>
Thread-Topic: [dtn] Re: [DNSOP] Re: Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Thread-Index: AQHayVQSDS//uY/+iUKcht8JHtCHKLHdGuJQ
Date: Fri, 28 Jun 2024 12:29:12 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F980273739B91@tss-server1.home.tropicalstormsoftware.com>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@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> <0910E1D8-C678-498C-BAB5-AC3AA4C75750@isc.org> <e364da36-00e3-7c14-30b0-34f20b244f0a@redbarn.org> <6ff67491-30cf-cdc0-5e19-c1122465386c@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F9802737395E2@tss-server1.home.tropicalstormsoftware.com> <8b864323-a43d-3861-17e6-9f422b2d4592@spacelypackets.com> <CAMzo+1at5W71ybFkchHBi8g1=fdF1L3mXqhZwZBGTtxbDnjj4A@mail.gmail.com>
In-Reply-To: <CAMzo+1at5W71ybFkchHBi8g1=fdF1L3mXqhZwZBGTtxbDnjj4A@mail.gmail.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: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F980273739B91tssserver1hom_"
MIME-Version: 1.0
Message-ID-Hash: VK46O6CWYMFSSUF2CP6FB6GGZSUYMGFX
X-Message-ID-Hash: VK46O6CWYMFSSUF2CP6FB6GGZSUYMGFX
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: Re: Re: 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/_nLXvcmRjytaMq5O17qXKxo5uVA>
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>
+1 From: Jorge Amodio [mailto:jmamodio@gmail.com] Sent: 28 June 2024 13:09 To: Scott Johnson Cc: Rick Taylor; Erik Kline; dnsop; sburleig.sb@gmail.com; dtn@ietf.org Subject: Re: [dtn] Re: [DNSOP] Re: Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171 Hi Scott, Just a suggestion, why not request a time slot during the next IETF WG meeting and put together a brief presentation including some basic examples showing how applications will benefit using this proposed DNS based solution ? Regards Jorge On Fri, Jun 28, 2024 at 4:12 AM Scott Johnson <scott@spacelypackets.com<mailto:scott@spacelypackets.com>> wrote: Hi Rick, As I have previously stated, I personally have lodged no objection to using CBOR encoding of (node-nbr) in this case, and actually mentioned the option myself. Here is the situation as I see it: I have requested the creation in the IANA database of the IPN and CLA RRTYPEs, by the means detailed in RFC6895, section 3.1.1; to whit, completed (twice, one for each) the form found in Appendix A. of same. My requests meet the criteria of part 2 of 3.1.1. I ran afound of section 3.1.2, point 1, as the Expert Reviewer explained that I needed to designate wire and presentation formats for the requested records, in Individual Informational internet-draft format. I produced that document, and, as suggested by Expert Reviewer, sent it to DNSOP for review. There, I received guidance on verbiage and optimal choice of formats from DNS expert Mark Andrews. I also consulted Scott Burleigh, first named author of RFC9171, for any particular BP related concerns. With the help of, and achieving concensus with these two learned individuals who possess significant specialized knowledge of the two systems we are integrating in the above described standardized process, we arrived at a viable document in several hours. Upon request of Transport AD, I forwarded to DTN. Of the productive responses received, Brian Sipos pointed out an interoperability problem with the notation I wove from whole cloth (based on the notation used in IPND) to describe CLAs, and you requested information concerning motivations of the document. Time being of the essense, I incorporated changes to address the point Brian made and added a section to text describing my motivation. I did so in short order, as I did previously with the consultations on DNSOP. You raised technical challenges to the proposed 64-bit integer wire encoding for IPN in this use case, citing RFC9171, and your own draft. Section 4.2.5.1.2 clearly defines the rules for encoding of EIDs. Only one component of EID is to be encoded in the RRTYPE, and hence, not an EID. Further, 64-bit integer is the preferred encoding of the DNS experts, and Scott Burleigh has confirmed that this proposal conforms to the encoding defined in your draft; an assertation which has not been refuted. It has also been confirmed that there is no conflict between the registration of these RRTYPEs in the described formats and the content of your draft. This particular encoding is not for use inside bundles or by BPAs; indeed, it will only appear (please correct me if i am wrong, DNSOP participants) internally inside nameservers and resolvers and on the wire between them. Thus, these technical challenges seem to have been addressed. An alternate proposal was put forward in theory, fulfilled in part by an expired draft by Brian Sipos, who has indicated that he does not have time to work on that solution at present. I believe him; I imagine his workplace is exceedingly busy of late. I know mine is. Having arrived at loose consensus with experts from both disciplines involved, and lacking a good reason to further revise the draft which is now before the Expert Reviewer for a decision as to the creation of the RRTYPEs, I think the best course of action is to let the Expert Reviewer do their job and approve or (hopefully not) deny the RRTYPE reservations. The IANA registry will likely reference my draft if approved, and I will likely be requesting at least one more RRTYPE to hold BPSEC data. If DTN WG wishes to take up this special purpose individual informational draft instead of other pressing business it is chartered for, it is free to do so. It is in no way necessary to do so to perfect my RRTYPE request procedure, and seems a waste of time to me. If you want something for the WG to take up, I will be producing another Informational draft soon which you will surely find interesting concerning discrete DNS networks on different planetary bodies interoperating by means of transiting IP request metadata across the BP deep space network. That, IMHO, is worthy of asking the attention of the group here assembled. Please understand; we are operating in an Adopt, Adapt, Author order of preference when it comes to solving real world problems being faced right now. In this case, 'Adopt'ing new DNS RRTYPEs to distribute BP information to IP speaking BP nodes fits the bill. It "just works" in a way that those who will use it will already understand, and is easy to implement all the way around. It may not be the best solution possible, but it was the best one available. Thanks, Scott On Thu, 27 Jun 2024, Rick Taylor wrote: > Hi Scott, > > <chair hat on> > > I absolutely sympathise with your need to "grab an RRTYPE and make progress", but there is a process choice to be made here: > > * Do DNSOPS want the RRTYPE registrations to integrate with the wider work of the DTN working group? In which case discussion like this must continue, and the document should be adopted by the WG. > * Or is everyone happy to register the RRTYPEs as "ScottJ and colleagues need some unique RRTYPEs for the solution they're working on - no alignment with the wider work of the DTN WG implied"? I would propose calling the RRTYPE NODEID not IPN to make this clear, and not have the reference specification be an IETF document. > > I'm genuinely not trying to scupper this work. I'm actually happy with either approach, I'm just trying to ensure moving fast doesn't accidently set perceived standards that then consume WG cycles in the future to align with current work. > > But before we consume too much more of all of our time, a decision needs to be made on the approach, and I think Erik (DTN AD), the DNSOPS Designated Experts/Chairs and Scott need to discuss their preferred options. > > We have "Naming and addressing" as part of the DTN WG charter, so this work could be adopted if the WG is willing, but that may not suit Scott's timeline. > > Cheers, > Rick > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org<mailto:dnsop@ietf.org> > To unsubscribe send an email to dnsop-leave@ietf.org<mailto:dnsop-leave@ietf.org> _______________________________________________ dtn mailing list -- dtn@ietf.org<mailto:dtn@ietf.org> To unsubscribe send an email to dtn-leave@ietf.org<mailto: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