Hi Alberto,

Like Scott B, I’m not going to “die on this hill”, but my issue is that an FQNN 
is soon to no longer be semantically 1 integer, but 2.

I take the point that to enable compatibility with existing implementations, 
the ipn-update (see 
https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-11.html) introduces a 
bit-shifting mechanism to encode two 32-bit unsigned integers in a single 
unsigned 64-bit integer, and that seems really simple to just re-use.  But 
reusing this technique perpetuates the idea that an FQNN is ‘just 1 value’ when 
it soon won’t be, and it prevents more flexible representations of FQNN ranges 
(see 
https://www.ietf.org/archive/id/draft-sipos-dtn-eid-pattern-02.html<https://www.ietf.org/archive/id/draft-sipos-dtn-eid-pattern-02.html#name-dtn-patterns>)
 that may be adopted in some form in the future.

As I believe the intention for the RRTYPE registration is to make rapid 
progress on something not destined for standardisation, I won’t stand in the 
way.  However, if whatever is being developed later comes back to the IETF for 
standardisation, I can see these and other discussions resurfacing, and 
unpicking these things later is just harder.

Cheers,
Rick



From: Alberto Montilla (SPATIAM) [mailto:a.monti...@spatiam.com]
Sent: 28 June 2024 11:05
To: sburleig...@gmail.com; Rick Taylor; 'Scott Johnson'; 'Mark Andrews'
Cc: 'Erik Kline'; 'dnsop'; d...@ietf.org
Subject: Re: [dtn] Re: [DNSOP] Re: Re: Re: IPN and CLA RRTYPEs to support 
Bundle Protocol RFC9171

FWIW;

I support Scott’s view. Returning the FQNN (integer) is probably the best way 
forward.

Rergards;
Alberto

From: sburleig...@gmail.com <sburleig...@gmail.com>
Date: Thursday, June 27, 2024 at 1:07 PM
To: 'Rick Taylor' <r...@tropicalstormsoftware.com>, 'Scott Johnson' 
<sc...@spacelypackets.com>, 'Mark Andrews' <ma...@isc.org>
Cc: 'Erik Kline' <ek.i...@gmail.com>, 'dnsop' <dnsop@ietf.org>, d...@ietf.org 
<d...@ietf.org>
Subject: [dtn] Re: [DNSOP] Re: Re: Re: IPN and CLA RRTYPEs to support Bundle 
Protocol RFC9171
Hi, Rick.  I would not fight to the death over this, but I am skeptical that 
having domain names map to node numbers encoded in CBOR, rather than to node 
numbers expressed as unsigned integers, would be advantageous.

My understanding is that RFC 9171 and later 
https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ define the CBOR 
encoding for BP ipn-scheme endpoint IDs.  Scott has indicated several times 
that he doesn't propose to return EIDs as resources; all he wants returned from 
a DNS lookup by domain name is the fully qualified node number (allocator 
number followed by node number) to which that name maps.

Section 6.1.1 of the dtn-ipn-update draft explains that the encoding of an FQNN 
is a 64-bit unsigned integer and explains how that integer value is 
constructed.  One could CBOR-encode that value, which would tell the recipient 
"Here's an unsigned integer" and indicate the number of octets occupied by that 
integer value.  But it would seem simpler (both in the definition and for 
implementations) to state in the resource record definition that "The value 
returned is a 64-bit unsigned integer", so that the recipient instantly knows 
how to handle it.

It is true that the CBOR representation could compress the returned value in 
many cases, but I would not expect that to be a significant advantage in DNS 
lookup traffic, which shouldn't be extremely heavy.

Again, not a life-or-death consideration for me, but I would prefer the simpler 
mechanism.

Scott

-----Original Message-----
From: Rick Taylor <r...@tropicalstormsoftware.com>
Sent: Thursday, June 27, 2024 1:32 AM
To: Scott Johnson <sc...@spacelypackets.com>; Mark Andrews <ma...@isc.org>
Cc: Erik Kline <ek.i...@gmail.com>; dnsop <dnsop@ietf.org>; 
sburleig...@gmail.com; d...@ietf.org
Subject: RE: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle 
Protocol RFC9171

Hi Both,

Comments inline...

> -----Original Message-----
> From: Scott Johnson [mailto:sc...@spacelypackets.com]
> Sent: 27 June 2024 04:36
> To: Mark Andrews
> Cc: Rick Taylor; Erik Kline; dnsop; sburleig...@gmail.com;
> d...@ietf.org
> Subject: Re: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support
> Bundle Protocol RFC9171
>
> Hi Mark,
>
> On Thu, 27 Jun 2024, Mark Andrews wrote:
>
> >> I broached the possibility of CBOR in discussion on DNSOP before
> >> DTN was CCed, making the above point to Scott Burleigh.  Our
> >> conclusion there, along with Mark Andrews, was that the current
> >> verbiage is the current best course of action.  I have no personal
> >> objection to wire format for the IPN RRTYPE being CBOR, if ScottB
> >> and Mark agree that there is gain to be had over using 64-bit unsigned int.
> >>
> >> That said, it is unclear if appropriate CBOR functions/libraries
> >> already exist/are used inside nameserver implementations. If not,
> >> that could substantially delay deployment, and/or add burden to
> >> implementers.  There is an active draft which specifically treats
> >> CBOR encoding of RRs (
> >> https://datatracker.ietf.org/doc/draft-lenders-dns-cbor section
> >> 3.2.1), but that document is still an Individual Draft at this point as 
> >> well.
> >>
> >> Mark, ScottB, opinions?
> >
> > What real benefit would CBOR bring over a raw 8 byte value other
> > than saying it was entered via X or X.X?
>
> This would be my criteria exactly.  If we can save bytes, ok; lets
> consider it.  If not, then why?

My point wasn't about saving bytes (but of course one doesn't want to go 
overboard and explode the total length) - as Scott B pointed out, this isn't a 
resource constrained use-case.

My point is about familiarity and commonality.  By the time someone has got 
their head around EIDs, NodeIds, Node Numbers, FQNNs, introducing yet another 
binary encoding to save some bytes seems a mistake.

RFC9171 (the source document for all of BP) has a well-defined CBOR encoding, 
which is updated in a forwards-compatible way in 
https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ (currently with 
IESG), so why not re-use it?  It has been intentionally designed such that if 
in the future NodeIds are expanded again (because 640K is never enough) the 
format is highly unlikely to need changing.  There is also following work 
within the WG adding 'wildcard' support, whilst still maintaining a consistent, 
efficient, self-descriptive format.

If the RRTYPE is encoding a 'data type' defined by a IETF, I would expect there 
to be a good reason to deviate from the IETF standard binary encoding.

Additionally I think it might make the RRTYPE defining document simpler: You 
can just normatively reference ipn-update.

Cheers,
Rick

_______________________________________________
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

Reply via email to