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

Reply via email to