As promised yesterday, here is a simple data structure with all the Input Conditions and Output Assertions for Section 5.2.2 of RFC9000. To begin, I structured 5.2.2. into the following simple declarative statements (constrained to a six-element finite grammar):
Input Conditions
1. The received packet is an Initial packet that fully conforms to the specification.
2. The received packet is a Handshake packet that arrived before any server response.
3. The received packet is type 0-RTT (Zero Round-Trip Time).
4. The received packet has a supported version.
5. The received packet has an unsupported version.
6. The received packet has no Version field.
7. The received packet has a size of ≥1200 bytes.
8. The received packet has a size of <1200 bytes.
9. The received packet has a zero-length Destination Connection ID.
10. The server refuses to accept the new connection.
Output Assertions
i. The server proceeds with the handshake using the version selected by the client.
ii. The server buffers a limited number of these packets in anticipation of a late-arriving Initial packet.
iii. The server sends a Version Negotiation packet.
iv. The server limits the number of Version Negotiation packet types sent.
v. The server matches the packet to a connection using the Destination Connection ID.
vi. The server matches the packet to a connection using the local address and port.
vii. The server sends an Initial packet containing a CONNECTION_CLOSED frame with error code CONNECTION_REFUSED
viii. The server ignores the out-of-sequence packet.
ix. The server drops the unsupported packet, by default.
1. The received packet is an Initial packet that fully conforms to the specification.
2. The received packet is a Handshake packet that arrived before any server response.
3. The received packet is type 0-RTT (Zero Round-Trip Time).
4. The received packet has a supported version.
5. The received packet has an unsupported version.
6. The received packet has no Version field.
7. The received packet has a size of ≥1200 bytes.
8. The received packet has a size of <1200 bytes.
9. The received packet has a zero-length Destination Connection ID.
10. The server refuses to accept the new connection.
Output Assertions
i. The server proceeds with the handshake using the version selected by the client.
ii. The server buffers a limited number of these packets in anticipation of a late-arriving Initial packet.
iii. The server sends a Version Negotiation packet.
iv. The server limits the number of Version Negotiation packet types sent.
v. The server matches the packet to a connection using the Destination Connection ID.
vi. The server matches the packet to a connection using the local address and port.
vii. The server sends an Initial packet containing a CONNECTION_CLOSED frame with error code CONNECTION_REFUSED
viii. The server ignores the out-of-sequence packet.
ix. The server drops the unsupported packet, by default.
The logic was then expressed in columns of an adjacent array, using the RuleMaker IDE.
Here is a screenshot of the interface showing the full Section 5.2.2 with logic in a graphical/numerical array.
Here is a screenshot of the interface showing the full Section 5.2.2 with logic in a graphical/numerical array.
(This can be illustrated with a spreadsheet.)
RuleMaker then generates a flat file package (or row in a RuleReserve table on IPFS) with the essential metadata and some optional descriptive data, followed by the rule's conditions, assertions, and logic. These last three items are structured into a Coordinates List based on a specialized array that is optimized for processing speed, with a single consistent structure for any rule and any related lookup table of reference data.
Background
I and a small team began working on this a decade ago, though some of the method go back 40 years. I met with Henrik Levkowetz during IETF105 (Montreal, 2019). Following that discussion I shared with him a pre-"Internet-Draft" exploratory document entitled: "An Experiment in Automated Discovery of 'In Effect' and 'Applicable' Technical Standards Requirements During Unit Testing". (Unfortunately this was a couple of weeks prior to Henrick stepping back from some of his key roles, so that discussion got interrupted.) Then, rather than talk more about the notion with no working system yet, I decided to hold off followup until colleagues and I had the concept operational with "running code".
Now, before putting in the effort to write a genuine Internet-Draft, I want to find out if there's sufficient interest in this among IETF contributors. So I'm just sharing the practical example of Section 5.2.2 from RFC9000, and the following excerpt from my 2019 document summarizing the purpose. If there's interest I can discuss details (the finite grammar; the four-valued logic; network optimization; etc.) at IETF124 in Montreal.
Problem: Voluminous, Verbose, Vague and Varying Technical Standards
At present there is no comprehensive, efficient way for informatics systems developers, even when well informed and committed to conformance with technical standards across their particular domains of specialization, to keep up with the thousands of sporadically updated standards requirements.
In addition to the large numbers of standards that are in effect and that may be applicable to particular functional elements of systems development projects, the requirements are sometimes expressed vaguely, or are embedded within a lot of explanatory text.
Even when specialists gain familiarity with standards in their own domain, they often need to learn promptly about technical standards in adjacent domains, in order to accommodate new deployment platforms, or adapt to new technological capabilities.
Inadvertent non-conformance by one or more sub-system developers can burden many others with operational work-arounds, weaken overall support for standards, constrict future market opportunities, and overlook legal, security and safety risks.
Objective: Test a New Method for Technical Developers to Keep Abreast of Technical Standards
The objective of this project is to experiment with a method to help network systems developers efficiently locate and maintain awareness of the global, multilateral and national technical standards in effect, and applicable to the particular functions of systems they are working on at any given time.
Automated Discovery of Sample IETF RFC Requirements from ‘Unit Test’ Data
This proposal is to experiment with a new method for making requirements of IETF RFC documents automatically ‘discoverable’ during developer unit tests performed while creating, maintaining or diagnosing Internet subsystems or services, using the existing contextual and operational data.
Considering ‘technical standards’ as rules, we suggest to replace commercial transaction events with developer ‘unit test’ events, building upon current work on a Standards-Specific Ontology Standard (SSOS) being undertaken by NISO, and upon the current Version 3 of IETF’s xml2rfc utilities. We would extend the schema as required, for example to include the “levels of requirement” defined in IETF BCP 14 (e.g. <MUST>, <MAY>, <SHOULD>) and related elements. An instance of Interlibr will be populated with rule.xalgo files containing ‘deontic control tables’ (Annex 2 and 3), to express the scenarios in which the rules contained in IETF RFC documents are ‘in effect’ and ‘applicable’.
A variety of sample unit tests will then be designed and performed to simulate the normal technical work involved in creating, maintaining or diagnosing Internet subsystems or services. Contextual and operational data from the unit tests will be received by an instance of the Lichen component, sent as requests to Interlibr, which should then find and return the correct requirements of technical standards.
Experimentation will begin with just two simple RFC documents, and expand:
• 1st Iteration: Requirements from two simple, well-established RFC documents.
• 2nd Iteration: Testing will expand to the requirements of twelve simple, well-established RFC documents, selecting two from each of the IETF’s six functional ‘Areas’.
• 3rd Iteration: Testing will extend to a selection of more complicated RFC documents.
The _expression_ of RFC requirements, and the performance of unit tests should involve as little additional work as practicable for RFC authors and users. Participation in this initiative will be oriented to developers who do typically write unit tests as they work, and are self-motivated to achieve and maintain conformance with technical standards.
Success in this experiment will be achieved if participating developers can easily and automatically ‘discover’ the correct sections of the sample RFC documents, using only the contextual and operational data generated from conventional or lightly modified unit tests. Should the experiment pass with the initial tests, additional RFC documents and unit tests will be designed to introduce greater complexity and uncertainty. This direction will be pursued and refined to determine the practical limit of utility with this method. Interim results will be reported to the IETF developer community, along with invitations for expanded testing.
***
BTW, apologies for taking the former thread on a tangent. It's not often that BCP14's MUST/MAY/SHOULD primitives come up for reconsideration. Since it came up, and Carsten provided an amusing riddle, I was curious to test how easy or hard it would be in RuleMaker to resolve his riddle into a hypothetical but workable "rule" the DWD way.
Joseph Potvin
Executive Director, Xalgorithms Foundation
Mobile: 819-593-5983
jpotvin@xxxxxxxxxxxxxxx
https://www.xalgorithms.org
Executive Director, Xalgorithms Foundation
Mobile: 819-593-5983
jpotvin@xxxxxxxxxxxxxxx
https://www.xalgorithms.org
On Mon, Sep 1, 2025 at 9:52 AM Joseph Potvin <jpotvin@xxxxxxxxxxxxxxx> wrote:
To X or X̅ , Y that is Z question.I've taken Carsten's "not so sure we want to enshrine specific phrasings [example] into further rulemaking" as a little exercise to see how it could be simplified in the Data With Direction Specification (DWDS). This is an end-to-end network service for normative data types (obligation, permission, and encouragement) concerning the terms MUST, MAY and SHOULD and their various negatives and synonyms, in any language.I presented the rudimentary concepts for this method in the IETF105 HotRFC Lightning Talks (2019), but that was four years before version 1.0.0 of the specification (2023). More info. We optimized the data structure this year, which I'll illustrate here, but documentation is catching up with the 'running code'.In a follow-up email I'll illustrate the "concrete example" that Christian Huitema suggested, i.e. Section 5.2.2 from RFC9000 https://www.rfc-editor.org/rfc/rfc9000.html#section-5.2.2 First though, to introduce this rules-as-data method, I'll stick with a shorter example. (I have to consider breaking 5.2.2 into more than one rule.)In the RuleMaker mini-IDE (code; now reaching version 4.0.0 this coming week, licensed Apache 2.0) I structured Carsten's normative example with the following simple declarative statements for Input Conditions and Output Assertions:INPUT CONDITIONS
1. Action X is done
2. Action ¬X is done
3. Get result Y
4. Get result ¬Y
5. Criterion Z is in effect
6. Result Y is LESS PREFERABLE
7. Result ¬Y is PREFERABLE
OUTPUT ASSERTIONS
i.Do action X
ii. Do action ¬XIn the DWDS data structure, logic is associated with this via an array of columns to the right. We use for the Input Conditions {00, 01, 10, 11} which means {No, Yes, Yes-AND-No, Yes-OR-No}. And we use use for the Output Assertions {00, 01, 10, 11} which means {NOT, MUST, MAY, SHOULD}. Some people don't like the Yes-AND-No item, but following Belnap we use this to accommodate conflicting data, paradoxes and various kinds of uncertainty. It's a compact Cartesian product that can express many nuanced policy positions. Here is the RuleMaker GUI for this rule where, in this case, you see six input scenarios, and their corresponding output assertion scenarios. For a production-class representation this particular rule can be reduced to just two columns (since there are only two Output combinations), however for illustration here it's easier to comprehend when all the combinations are shown.The export from RuleMaker is a flat 'rules-as-data' file which begins with metadata about the rule, and some additional descriptive attributes designed to assist in rule discovery with the RuleTaker embedded component (rows 1-45), followed by the logic gate condensed into a 'DWD Coordinates List' (in this case, rows 46-120). These are coordinates from a DWD Array, which is a sparse table structured with all the text strings to the left, with numerically indexed columns containing just 0 and 1. In the top section are all the combinations of the logic gate labels systematically laid out. In the bottom section there is an identity array (diagonal line of cells containing 1 in a sparse array of cells containing 0). Here is how that looks in a spreadsheet when all the cells containing 1 are highlighted. Here is the spreadsheet (LibreOffice Calc) for anyone who wants a closer look at the details.The flat rules-as-data file containing the compressed Coordinates List logic gate can be saved from RuleMaker locally, or directly posted by RuleMaker to an IPFS RuleReserve subset node (licensed AGPL 3.0; easy to rewrite and relicense if preferred), referenced with a CID. There, each rule becomes a row in a large distributed table. Then any system with a RuleTaker component (≈200 lines of code, licensed Apache 2.0) can automatically discover the rule by running an algorithm on a RuleReserve subset using the metadata to sift for "in effect" & "applicable", and fetch it. Once this rule (row) is obtained locally, another 'sift' algorithm run by RuleTaker determines which column(s) of the logic gate are picked out by the circumstantial data. Unlike conventional decision tables, these can have more than one result because they incorporate ambiguity -- which means the next step involves "Human in the Loop".On this point I offer an important side note regarding Rob Wilton's suggested revision of RFC 2119: "A slightly out-there suggestion could be to update RFC 2119 to remove SHOULD/SHOULD NOT and introduce MUST … UNLESS and MUST NOT … UNLESS as their replacements." Among many normative philosophers there is a fundamental distinction between MUST (where the conformance prerogative rests with the rule maker) and SHOULD (where the conformance prerogative rests with the rule taker). Other normative philosophers consider SHOULD to be just a soft MUST. That informality is fine for many circumstances. But when designing systems that could be wholly or partially automated, the locus of prerogative is critical....getting back to the point where RuleTaker determines which column(s) of the logic gate are picked by the circumstantial data, the Output Assertions which are "invoked" with MUST; MAY; SHOULD symbols can then be acted upon by the local application, on any platform (from a supercomputing cluster to a nano-IoT bot), in any programming language.All rules and their related lookup tables can be expressed with the same lattice structure, allowing simple tooling that only needs to interpret a single kind of matrix.Now I'll structure Section 5.2.2 from RFC9000. For now I hope this little illustration conveys the potential general purpose utility of DWDS.Joseph Potvin
Executive Director, Xalgorithms Foundation
Mobile: 819-593-5983
jpotvin@xxxxxxxxxxxxxxx
https://www.xalgorithms.org---------- Forwarded message ---------
From: Carsten Bormann <cabo@xxxxxxx>
Date: Sat, Aug 30, 2025 at 3:25 AM
Subject: Re: Question about BCP 14 / RFC 8174
To: Christian Huitema <huitema@xxxxxxxxxxx>
Cc: <ietf@xxxxxxxx>
On Aug 30, 2025, at 07:15, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
>
> Not that SHOULD effectively means "MUST UNLESS". That is, "You SHOULD do this" is equivalent to "You MUST do this, unless you have a very good reason not too" ... but the reason is generally left unstated, except in the "SHOULD but MAY" construct as in the examples above.
For a previous message, I asked an LLM to find BCP 14 SHOULD/RECOMMENDED usages without stated exception conditions, for example in RFC 8949.
It found some, including a NOT RECOMMENDED in
https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4-10
Good to know that an LLM can help finding these.
But in this case, the whole paragraph is there to alert the registrant (who is the one addressed by the NOT RECOMMENDED) about the undesirable consequences of an exception to this NOT RECOMMENDED.
So I think in this instance we are well within the spirit of what is being discussed here.
This makes me not so sure we want to enshrine specific phrasings of the "You SHOULD do X because if you don’t, you get Y, which is less preferable because Z” (here: You SHOULD NOT do X̅ because if you do, you don’t get Y̅, which is preferable because Z) into further rulemaking.
Grüße, Carsten
