[secdir] Re: [Cbor] Secdir last call review of draft-ietf-cbor-update-8610-grammar-05

[Carsten Bormann <[e-mail]>]

Hi Yaron,

thank you for this review.

> On 2024-05-26, at 23:37, Yaron Sheffer via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Yaron Sheffer
> Review result: Ready
> 
> This document describes the results of applying several errata to the CDDL
> specification.
> 
> I concur with the Security Considerations section that the current document
> likely has zero security implications beyond what's in RFC 8610.

Thank you.

> I am clearly in the rough, but I'll say it anyway: from an implementer's
> perspective, a document that repeats all of RFC 8610 with the errata
> implemented (and clearly marked) would have been far superior to this one.

Superior: Probably.
(For those who already have implemented RFC 8610, having a short “update” document is actually more helpful; we are certainly unable to ship a -bis that leads to a clean diff…)

> Instead, we now require an implementer to read and keep in sync RFC 8610, RFC
> 9165 as well as the current document.

I’m not sure RFC 9165 is of the same class:
This exercises a well-defined extension point (control operators) of RFC 8610.
There is already a new set of such extensions underway [1], and applications often define their own control operators [2].
These little extensions are quite independent from each other, so there is little difference between having them all in one document or having them spread out over many.
The registry [3] serves as the focal point where they all flow together.
So I would expect an implementer to be fully prepared to look at multiple documents here.

[1]: https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-more-control-04.html
[2]: https://www.rfc-editor.org/rfc/rfc9090.html#name-cddl-control-operators-2
[3]: https://www.iana.org/assignments/cddl/cddl.xhtml#cddl-control-operators

> Quoting from RFC 8610 itself: "Writers of CDDL specifications are strongly
> encouraged to value clarity and transparency of the specification over its
> elegance. Keep it as simple as possible while still expressing the needed data
> model."
> 
> This reviewer is of the opinion that having to juggle three documents is
> neither clear nor transparent.

Focusing on the two documents RFC 8610 and draft-ietf-cbor-update-8610-grammar, I’d say:

* Doing a grand -bis is certainly in the cards.
  For RFC 7049/8949, we did this after about seven years.
  Seven years after June 2019 would be June 2026, so we could start preparing for this now.

* At least the ABNF comes in an integrated, -bis-like form with draft-ietf-cbor-update-8610-grammar.

* We do have a few small extensions/related documents on the plate for RFC 8610 [1] [4] [5] [6] [7], so it would be preferable to have those completed first before undertaking a -bis, so a -bis might happen after those have accumulated some good amount of implementation experience, too.

[4]: https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/
[5]: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-modules/
[6]: https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/
[7]: https://datatracker.ietf.org/doc/draft-ietf-cbor-packed/

* It is generally much more expensive in WG and IESG time to review a full -bis than to review small incremental documents, and we may be optimizing our products for this aspect instead of for implementer convenience.

So I think we did the right thing here.
But update vs. -bis is definitely a question we should always ponder. I’d say quite subjectively that the choice is taken way too often on the update-on-update-on-update side for many existing documents (and I’d venture to say, particularly so for security documents!).

Grüße, Carsten