Re: [Cbor] Fwd: New Version Notification for draft-lenders-dns-cbor-03.txt

[Christian Amsüss <[e-mail]>]

Hello Martine,
hello Carsten and Henk (for item 1),

On Mon, Jul 10, 2023 at 04:24:52PM +0200, Martine Sophie Lenders wrote:
> FYI! Only some minimal changes, but hopefully after IETF 117 there will be
> more activity in this draft.

I've read through the document, and have a few questions and comments:

1. `domain-name = tstr .regexp "([^.]+\.)*[^.]+"`: A current draft in
   CoRE, draft-ietf-core-href, also deals with host names encoded in
   CBOR, but picks a different representation:

   host-name   = (*text) ; lowercase, NFC labels

   That is, rather than expressing some.hostname.example.com as
   `"some.hostname.example.com"`, it goes for `"some", "hostname",
   "example", "com"`, which is shorter by 1 byte in this example as long
   as host-name is not put into an aray. Admittedly, for lengths below
   24, or when individual components exceed the 24 threshold, those
   numbers change.

   Note that having the host-name components directly in rr (without an
   array) is still unambiguous w/rt optional components: After the last
   string item, the second integer is record-type if there are more than
   2 CBOR items remaining, otherwise it's int typed rrdata. For the
   encoding in dns-query, I think it's unambiguous as well (but I'm a
   bit confused by the plurals in names).

   One benefit of encoding the name this way is that a dot (".")
   character can be expressed as part of a name component. Such names
   are rare when DNS is used to resolve a URI (because while URIs can do
   percent encoding of dots, those do not survive URI normalization),
   but can occur in service names of DNS-SD.

   Aligning the documents might help implementations reduce duplication,
   and is also more in line with how names are encoded in DNS messages;
   has such an encoding been considered?

   If it has and it was chosen not to go that way: The choice to go with
   semantically split name in core-href was, to my understanding,
   motivated in part by alignment with how DNS represents names. If the
   representation of DNS messages we have in CBOR does *not* go that
   way, core-href's approach would be the odd one out.

2. "if the DNS transport can not ensure the prevention of DNS response
   spoofing": With the current stance of dns-over-coap toward unprotected
   requests, do we still need the transaction ID?

   There is already a lot of optionality for a message recipient to
   process. Having a field there that merely serves as stopgap measure
   for an already discouraged mode of operation seems to be too much to
   me.

3. "If an index in the packing table is referenced with shared item
   reference": Is this just restating how packed CBOR works when using
   tag 113? Maybe this and the later packing table discussion has been
   resolved in packed -09.

4. Are the packing tables pre-populated with any values? ("_coap._udp."
   and ".com" would come to mind). If so, is the 1 in `;packed=1`
   intended to serve as an extension point that dispatches the values of
   the table?

BR
Christian
(as individual)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom