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
