Requirements for a list

[seebees]

Requirements can be expressed as a list like this:
https://tools.ietf.org/rfc/rfc8446#section-9.2

All implementations MUST send and use these extensions when offering
   applicable features:
   -  "supported_versions" is REQUIRED for all ClientHello, ServerHello,
      and HelloRetryRequest messages.
   -  "signature_algorithms" is REQUIRED for certificate authentication.
   -  "supported_groups" is REQUIRED for ClientHello messages using DHE
      or ECDHE key exchange.
   -  "key_share" is REQUIRED for DHE or ECDHE key exchange.
   -  "pre_shared_key" is REQUIRED for PSK key agreement.
   -  "psk_key_exchange_modes" is REQUIRED for PSK key agreement.

But not all lists have requirements for every element.
To accommodate this this the requirements would break the list into chunks that can be composed.
Users can then choose how they want to cover each element.

So for the following
https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-7.3

   An endpoint MUST treat the following as a connection error of type
   TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
   *  absence of the retry_source_connection_id transport parameter from
      the server after receiving a Retry packet,
   *  presence of the retry_source_connection_id transport parameter
      when no Retry packet was received, or
   *  a mismatch between values received from a peer in these transport
      parameters and the value sent in the corresponding Destination or
      Source Connection ID fields of Initial packets.

A user could reference each element in different files like this:

//= https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-7.3
//# An endpoint MUST treat the following as a connection error of type
//# TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
//# *  absence of the retry_source_connection_id transport parameter from
//#   the server after receiving a Retry packet,
if (missing_source_connection_id) err()

//= https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-7.3
//# An endpoint MUST treat the following as a connection error of type
//# TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
//# *  presence of the retry_source_connection_id transport parameter
//#   when no Retry packet was received, or
if (no_retyr_packet) err()

//= https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-7.3
//# An endpoint MUST treat the following as a connection error of type
//# TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
//# *  a mismatch between values received from a peer in these transport
//#   parameters and the value sent in the corresponding Destination or
//#  Source Connection ID fields of Initial packets.
if (mismatch) err()

This also facilitates cases like this

You MUST pick one of the following:
* broccoli
* potatoes
* carrots

In this case there would be one annotation for potatoes obviously,
and broccoli and carrots would be exceptions because potatoes was selected.

Finally in a case where the MUST applies to every element like this:

On initialization, the caller MUST provide:
*  An AWS KMS key identifier
*  An AWS KMS SDK client

A single section that covers this whole list.

//=master_key_spec.txt#2.1
//# On initialization, the caller MUST provide:
//# *  An AWS KMS key identifier
//# *  An AWS KMS SDK client

How these elements are selected would be part of the report UI.
I would expect this last one to be the result of selecting the "list heading"
and each of the elements from selecting each element.