> On 27 Jun 2024, at 09:57, Scott Johnson <sc...@spacelypackets.com> wrote:
>
> Hi Rick,
>
> On Wed, 26 Jun 2024, Rick Taylor wrote:
>
>> Hi Scott,
>>
>> I would ask one change please. The wire format for ipn EID is well
>> documented in RFC9171, and updated in the forthcoming ipn-update. Please can
>> you use the CBOR encoding?
>
>
> 4.2.5.1.2 of RFC9171 indeed documents ipn EID well:
> "Encoding considerations:
> For transmission as a BP endpoint ID, the scheme-specific part of a URI of
> the ipn scheme SHALL be represented as a CBOR array comprising two items. The
> first item of this array SHALL be the EID's node number (a number that
> identifies the node) represented as a CBOR unsigned integer. The second item
> of this array SHALL be the EID's service number (a number that identifies
> some application service) represented as a CBOR unsigned integer. For all
> other purposes, URIs of the ipn scheme are encoded exclusively in US-ASCII
> characters."
>
> The key point is in the first sentence; "For transmission as a BP endpoint
> ID..." As has been previously noted, no EID is being transmitted, only the
> (node-nbr) component. I initially considered this to read that we were
> restricted to US-ASCII only, but when I realized that these encoding
> standards only apply to fully formed URIs, it made sense that unsigned 64-bit
> integer was acceptable for RR look-up wire encoding of (node-nbr), since no
> BPA would be using this representation in an actual bundle.
>
> Regarding draft-ietf-dtn-ipn-update, it appears that the wire format
> described fully and precisely complies with Two-Element Scheme-Specific
> Encoding in section 6.1.1.
>
> 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?
The CBOR encoding is going to be as long or longer in most cases on an internet
wide scale. It’s also going to require
more complicated validators other than the record length is 8.
0.0 -> 82 00 00
0 -> 00
3467.8979 -> 82 19 34 67 19 23 13
70000.500 -> 82 1a 00 01 11 70 19 01 f4
I hope I’ve got the hand encoding right.
This is not to say that CBOR couldn’t be used. I’m just not seeing the benefit.
We already do stuff like this so CBOR complexity itself isn’t a issue.
static isc_result_t
check_private(isc_buffer_t *source, dns_secalg_t alg) {
isc_region_t sr;
if (alg == DNS_KEYALG_PRIVATEDNS) {
dns_fixedname_t fixed;
RETERR(dns_name_fromwire(dns_fixedname_initname(&fixed), source,
DNS_DECOMPRESS_DEFAULT, NULL));
/*
* There should be a public key or signature after the key name.
*/
isc_buffer_activeregion(source, &sr);
if (sr.length == 0) {
return (ISC_R_UNEXPECTEDEND);
}
} else if (alg == DNS_KEYALG_PRIVATEOID) {
/*
* Check that we can extract the OID from the start of the
* key data.
*/
const unsigned char *in = NULL;
ASN1_OBJECT *obj = NULL;
isc_buffer_activeregion(source, &sr);
in = sr.base;
obj = d2i_ASN1_OBJECT(NULL, &in, sr.length);
if (obj == NULL) {
ERR_clear_error();
RETERR(DNS_R_FORMERR);
}
ASN1_OBJECT_free(obj);
/* There should be a public key or signature after the OID. */
if (in >= sr.base + sr.length) {
return (ISC_R_UNEXPECTEDEND);
}
}
return (ISC_R_SUCCESS);
}
>> As an a side, could you describe the needs of your application, I didn't
>> quite understand your HTTP request analogy, as that is a early-bind usage,
>> and BP is built on the concept of late-binding.
>
> Again, sorry, but per the Note Well, the information I placed in the
> "Purpose" section of the draft, per your request, is all I am at liberty and
> willing to disclose at this time.
>
> Thanks,
> ScottJ
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
