Page History

Terminology

This section asserts the terminology conventions used in the GF. It:

1. MUST explicitly specify the use of the ToIP Governance Requirements Glossary (see below).
2. SHOULD specify that all RFC 2119 keywords used with their RFC 2119 meanings are capitalized.
3. MUST reference the Glossary for all other terms (see the Controlled Documents section).
4. SHOULD specify any other formatting or layout conventions used in the Primary Document or Controlled Documents.

ToIP Governance Requirements Glossary

• Requirements include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119. 
  • Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
  • Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
  • Options are Requirements that use a MAY or OPTIONAL keyword.
• Machine-Testable Requirements are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software.
  • Rules are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the GF.
• Human-Auditable Requirements are those with which compliance can only be verified by an audit of people, processes, and procedures.
  • Policies are Human-Auditable Requirements written using standard conformance terminology. For Policies using in ToIP Governance Frameworks, the standard terminology is  RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented.
• Specifications are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability.

Governance Authority and Governing Party

This section asserts the legal authority for governance of the GF. It:

1. MUST state whether the Governance Authority or interdependent Governance Authorities are the same as the Governing Party.
2. MUST state the full legal identity of each Governance Authority (and the Governing Party, if separate).
   1. SHOULD provide an LEI for each.
3. MUST provide contact information for the Governing Party.
4. SHOULD provide a publicly-accessible website for accessing the GF.
5. It RECOMMENDED that this website:
   1. Be an independent dedicated website with its own  URL for portability and ease of management.
   2. If applicable, use a URL closely associated with the primary Trust Mark for the GF and display this Trust Mark prominently on the home page.
   3. Include HTML versions of all documents in the GF.
   4. Include PDF versions of all documents in the GF.
   5. Highlight the documents in the Governance Requirements section that specify how the Governance Authority itself is governed.
   6. Provide specific contact information for each Individual responsible in a public-facing Role for administering the GF and accepting public inquires or feedback.