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 <sc...@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 > > To unsubscribe send an email to dnsop-le...@ietf.org > > _______________________________________________ > dtn mailing list -- d...@ietf.org > To unsubscribe send an email to dtn-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
