[DNSOP] Re: [core] Re: Fwd: WG Adoption Call for draft-lenders-core-coap-dtls-svcb

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

Hello  Rich,

> I'm also surprised by the choice of mnemonic, which is very short.  If
> the extra 7 octets of "coap-dtls" would make a material difference in
> some use case, perhaps the draft should explain that.

This was mentioned just very briefly during the tls-reg-review[1], so
I'm happy to elaborate here. I have no current use cases where they hit
the precise boundaries, but two observations:

* In general, CoAP is one of the IETF protocols used in situations where
  sizes matter a lot -- while a DTLS messages usually fit well within a
  UDP MTU, CoAP is designed for running over fragmenting link layers,
  and the Client Hello and Server Hello are just the messages that
  already fragment[2]. With cTLS[3] being worked on, there is hope to
  push those below the fragmentation threshold -- provided we don't add
  too much on top of it while cTLS is shrinking.

* The process of designing EDHOC to fit with its required use cases
  involved byte shaving and just barely fit some of the maximum lengths.
  [4] describes how going over a fragmentation limit can cause
  exhaustion of slots and thus delay onboarding by an hour. To my
  understanding, DTLS/cTLS is not aiming for that precise space, but it
  does illustrate that this byte shaving around CoAP is not a vain
  exercise.

I think that these considerations are well understood among CoAP users
(who are the main audience of this document); if you prefer an
explanation in the document, we're happy to elaborate there as well.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/browse/tls-reg-review/?gbt=1&index=RiTWJ3-vE95YQ76Zk3VZySB4YEs
[2]: https://dl.acm.org/doi/pdf/10.1145/3609423#page=12
[3]: https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/
[4]: https://www.ietf.org/archive/id/draft-ietf-lake-reqs-04.html#name-time

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