Rationales for Standards

Some working groups for the standardisation of programming languages (like Ada or C) publish rationales. They explain the broader goals of their respective standard (or the current iteration of the standard), roads not taken, non-obvious problems with other approaches, and so on. Of course, they are only informative, not normative, because you want the normative part to be rather concise. That’s not only because normative parts carry greater burdens of effort, but also because you want to make sure that explaining things in an easier way or giving a second, duplicative approach towards one issue should really not lead to contradictions. And I really wish the security standards world would do rationales. The rather old draft of IEC 62443-1-1 that I’ve seen actually had a rationale annex which was super helpful in explaining why the standard is moving from IACS (industrial automation control system) to ACS (automation and control system). But the other parts leave questions open, at…