Revert "Examples for documents (#352)"

This reverts commit 506a85d.
SovereignCloudStack · Apr 3, 2024 · 37efde6 · 37efde6
1 parent c30d085
commit 37efde6
Show file tree

Hide file tree

Showing 6 changed files with 7 additions and 23 deletions.
diff --git a/Standards/scs-0001-v1-sovereign-cloud-standards.md b/Standards/scs-0001-v1-sovereign-cloud-standards.md
@@ -18,12 +18,12 @@ It strives for interoperable and sovereign cloud stacks
 which can be deployed and used by a wide range of organizations and individuals.
 Wherever feasible,
 transparency and openness both in respect to the inner workings of the platforms standardised by SCS,
-and the SCS organization itself
+as well as the SCS organisation itself
 are a paradigm we intend to live.
 
 ## Requirements
 
-The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
 
 In addition, "FORBIDDEN" is to be interpreted equivalent to "MUST NOT".
 
@@ -288,7 +288,7 @@ it can be deprecated.
 Obsoletions SHOULD be announced ahead of their execution by setting the
 `deprecated_at` field to a future date and moving the `status` to `Deprecated`.
 This signals current and future implementors
-that the subject of the document
+that the subject matter of the document
 is not considered necessary or state of the art anymore.
 
 If one or more replacement documents for the document exists,
@@ -340,7 +340,7 @@ The advantages of such an approach are:
 The disadvantages of that approach are:
 
 - It is possible to make breaking changes after stabilization.
-  Potentially, a hypothetical SCS-1234 document might refer to something completely different
+  Potentially, an hypothetical SCS-1234 document might refer to something completely different
   in a hypothetical R15 release than what it meant in R5,
   if there have been sufficient, gradual breaking changes to the document.
 

diff --git a/Standards/scs-0100-v3-flavor-naming.md b/Standards/scs-0100-v3-flavor-naming.md
@@ -20,14 +20,6 @@ but try to avoid changing in incompatible ways.
 (See at the end for the v1 to v2 transition where we have not met that
 goal, but at least managed to have a 1:1 relationship between v1 and v2 names.)
 
-## Terminology
-
-Error correction code memory (abbr. ECC memory)
-  Memory able to detect and correct n-bit data corruption
-
-L1 Terminal Fault (abbr. L1TF)
-  Speculative execution vulnerability on Intel processors
-
 ## Motivation
 
 In OpenStack environments there is a need to define different flavors for instances.

diff --git a/Standards/scs-0111-v1-volume-type-decisions.md b/Standards/scs-0111-v1-volume-type-decisions.md
@@ -17,7 +17,7 @@ We want to standardize a few varieties of volume types. While a user can choose
 
 In General: what the different volume types are capable of is highly dependend on both the used backend and the configurations of OpenStack. A few options are worth being at least recommended.
 
-## Context
+## Design Considerations
 
 We want to have a discoverable Standard. So there should be no naming conventions as per request by operators.
 

diff --git a/Standards/scs-0210-v2-k8s-version-policy.md b/Standards/scs-0210-v2-k8s-version-policy.md
@@ -28,14 +28,6 @@ Patches to these releases are provided monthly, with the exception of the first
 which is usually provided 1-2 weeks after the initial release (see [Patch Release
 Cadence][k8s-release-cadence]).
 
-## Terminology
-
-Common Vulnerabilities and Exposures (abbr. CVE)
-  System to provide a references for publicly known information-security vulnerabilities and exposures
-
-Cloud Native Computing Foundation (abbr. CNCF)
-  Linux Foundation project that was founded to help advance container technology
-
 ## Motivation
 
 Kubernetes is a living, fast-paced project, which follows a pre-defined release cycle.

diff --git a/Standards/scs-0211-v1-kaas-default-storage-class.md b/Standards/scs-0211-v1-kaas-default-storage-class.md
@@ -24,7 +24,7 @@ While often times, consumers will choose a `StorageClass` explicitly, usually, t
 
 This document attempts to define the properties this default `StorageClass` should have.
 
-## Standard
+## Decision
 
 The default `StorageClass` is made default using the `storageclass.kubernetes.io/is-default-class` annotation, following [Kubernetes upstream](https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/). Hence, standardizing its name is not required for the intents of this standard.
 

diff --git a/Standards/scs-0302-v1-domain-manager-role.md b/Standards/scs-0302-v1-domain-manager-role.md
@@ -55,7 +55,7 @@ To address this, this standard defines a new Domain Manager role in conjunction
 3. The cloud admin creates one or more users within each of the applicable domains and assigns the Domain Manager role to them. These users represent the Domain Managers of the corresponding domain.
 4. The customer uses the Domain Manager users to manage (create, update, delete) users, projects, groups and corresponding role assignments within their domain.
 
-## Context
+## Design Considerations
 
 - the Domain Manager role MUST support managing projects, groups and users within a specific domain
 - the Domain Manager role MUST be properly scoped to a domain, it MUST NOT gain access to resources outside of its owning domain