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

[Scott Johnson <[e-mail]>]

Hi Jorge,

Per Note Well, I am not sure this cat will be ready to get out of the bag 
for Vancouver.  Perhaps Dublin...

Scott

On Fri, 28 Jun 2024, Jorge Amodio wrote:

> 
> 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
> <[e-mail]> 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 -- [e-mail]
>       > To unsubscribe send an email to [e-mail]
>
>       _______________________________________________
>       dtn mailing list -- [e-mail]
>       To unsubscribe send an email to [e-mail]
> 
> 
>