Hi Yaron, thank you for this review. > On 2024-05-26, at 23:37, Yaron Sheffer via Datatracker <noreply@xxxxxxxx> 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
