Versions Compared

Old Version 71

changes.mady.by.user Drummond Reed

Saved on

compared with

New Version 72

changes.mady.by.user Drummond Reed

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The balance of this page defines the proposed metamodel and the requirements for each component. In these requirements, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" are to be interpreted as defined in RFC 2119.

All terms appearing in First Letter Caps on this page MUST be added to the ToIP Glossary tagged for inclusion in the ToIP Governance Glossary. (Note: the Concepts and Terminology WG has been briefed on this dependency.) The following special glossary defines terms used in this document:

Table of Contents

Primary Document

The Primary Document is the "home page" for the governance framework (GF). It:

  1. MUST have a DID (Decentralized Identifier) that serves as an identifier of the entire GF.
  2. MUST have a unique DID URL (defined in the DID spec) to identify each specific version of the Primary Document.
  3. MUST contain authoritative references to all other documents included in the GF, called the Controlled Documents.
  4. MUST include Policies in the Revisions section stating how the Controlled Documents are governed by the Governance Authority.

Introduction

This section is a non-normative general introduction to the GF whose purpose is to orient first-time readers as to the overall context of the GF. It:

  1. SHOULD have a reference to the ToIP Foundation, the ToIP Stack, and the specific version of the ToIP Governance Template from which it was derived.
  2. MAY include an "Acknowledgements" section to acknowledge the contributors to the GF.
NEW
Info
titleNew

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.
Info
title

ToIP Governance Requirements Glossary

Info
titleNew

Terminology

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

  • MUST explicitly specify the use of the ToIP Governance Requirements Glossary (see above).
  • SHOULD specify that all RFC 2119 keywords used with their RFC 2119 meanings are capitalized.
  • MUST reference the Glossary for all other terms (see the Controlled Documents section).
    • SHOULD specify any other formatting or layout conventions used in the Primary Document or Controlled Documents
    • 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.

    Table of Contents

    Primary Document

    The Primary Document is the "home page" for the governance framework (GF). It:

    1. MUST have a DID (Decentralized Identifier) that serves as an identifier of the entire GF.
    2. MUST have a unique DID URL (defined in the DID spec) to identify each specific version of the Primary Document.
    3. MUST contain authoritative references to all other documents included in the GF, called the Controlled Documents.
    4. MUST include Policies in the Revisions section stating how the Controlled Documents are governed by the Governance Authority.

    Introduction

    This section is a non-normative general introduction to the GF whose purpose is to orient first-time readers as to the overall context of the GF. It:

    1. SHOULD have a reference to the ToIP Foundation, the ToIP Stack, and the specific version of the ToIP Governance Template from which it was derived.
    2. MAY include an "Acknowledgements" section to acknowledge the contributors to the GF.
    • .

    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.

    ...