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

[Martine Sophie Lenders <[e-mail]>]

Hi Christian,

Replies inline below.

On 24.07.23 12:28, Christian Amsüss wrote:
> 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.

In general, this sounds like an interesting idea.

~24-25 is, from our studies of IXP and (consumer-grade) IoT traffic, the 
median for the length of names, with the mean being around 26. But 
ideally, for the constrained IoT, it should be lower…

>     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).

Where did you see those plurals?

>     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.

In general, as stated above, I like the idea. Especially, since this 
could make de- and encoding easier with DNS wire (just mask tstr type 
identifier in the delimiter bytes). However, with your later mail below, 
I am not sure if it is more hassle than it is worth in the scope of DNS 
when using CBOR packed. But maybe we can find a nice solution that can 
serve both.

On 24.07.23 13:37, Christian Amsüss wrote:
 > On Mon, Jul 24, 2023 at 01:16:42PM +0200, Carsten Bormann wrote:
 >> On 24. Jul 2023, at 12:28, Christian Amsüss <[e-mail]> 
wrote:
 >>>
 >>> 4. Are the packing tables pre-populated with any values? ("_coap._udp."
 >>>    and ".com" would come to mind).
 >>
 >> (Or the corresponding arrays, if DNS names are carried in parsed form…)
 >
 > With the parsed form, that may actually prove to be difficult to use.
 >
 > It'd work if arrays are used, because then
 >
 >      [0, 1, 2, ["_coap", "_udp", "example", "com"], 4, 5]
 >
 > can become
 >
 >      [0, 1, 2, tag-prefix:coap-udp(tag-suffix:com("example")), 4, 5]
 >
 > but if the parsed form is used in-line (as it is done with CRIs),
 >
 >      [0, 1, 2, "_coap", _udp", "example", "com", 4, 5]
 >
 > is not that obviously compressible because we have neither infix
 > expansion like
 >
 >      tag-infix:coap-udp([[0, 1, 2], tag-infix:com([["example"], [4, 5])])
 >
 > nor generic concatenation like
 >
 >      tag-chain([[0, 1, 2], tag-immediate:coap-udp, ["example"], 
tag-immediate:com])


> 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.

Yeah, with the direction draft-ietf-core-dns-over-coap is currently 
going, the DNS transaction ID might indeed not be necessary anymore.

> 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.

I think, when that sentence was written, the concept of common tables, 
as presented in -09, did not exist yet and it was meant to define the 
behavior for a single table. I will take a look at the current state of 
draft-ietf-cbor-packed and will come back to that.

> 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?

There are plans to explore this (see last point on my last slide for the 
meeting today [1]). I really like the idea of using the number in the 
media type parameter for the extension point! (It will mean however, 
that we might need a bit more content-format numbers than originally 
expected.)

Best regards
Martine

> BR
> Christian
> (as individual)
>

[1] 
https://datatracker.ietf.org/meeting/117/materials/slides-117-cbor-a-concise-binary-object-representation-cbor-of-dns-messages