From 05277ff704f98a22f5918b456dbbb341b11a3a29 Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Tue, 2 Sep 2025 15:07:40 +0200 Subject: [PATCH 1/4] A typo and a few wording changes. This is only to improve English language without any changes w.r.t. content. Signed-off-by: Kurt Garloff --- .../scs-0121-w1-Availability-Zones-Standard.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Standards/scs-0121-w1-Availability-Zones-Standard.md b/Standards/scs-0121-w1-Availability-Zones-Standard.md index b5905906d..645422ca4 100644 --- a/Standards/scs-0121-w1-Availability-Zones-Standard.md +++ b/Standards/scs-0121-w1-Availability-Zones-Standard.md @@ -10,7 +10,7 @@ supplements: The standard will not preclude small deployments and edge deployments, that both will not meet the requirement for being divided into multiple Availability Zones. Thus multiple Availability Zones are not always present. -Somtimes there can just be a single Availability Zones. +Somtimes there can just be a single Availability Zone. Because of that, there will be no automated tests to search for AZs. ## Required Documentation @@ -24,11 +24,11 @@ For each deployment, that uses more than a single Availability Zone, the CSP has 4. The redundancy in external connection within each AZ MUST be documented. 5. The redundancy in core routers within each AZ MUST be documented. -All of these requirements will either not change at all like the fire zones or it is very unlikely for them to change like redundant internet connection. -Because of this documentation must only be provided in the following cases: +After the initial setup, these requirements typically do not change at all (like the fire zones) or are very unlikely to change (like redundant internet connection). +Because of this, documentation needs to only be provided in the following cases: -1. When a new deployment with multiple AZs should be tested for compliance. -2. When there are physical changes in a deplyoment, which already provided the documentation: the changes needs to be documented and provided as soon as possible. +1. When a new deployment with multiple AZs should be tested for compliance initially. +2. When there are physical changes in a deployment, which already provided the documentation: the changes needs to be documented and provided as soon as possible. ### Alternative Documentation @@ -37,5 +37,5 @@ It is still required to document the existence of fire zones and the correct con ## Physical Audits -In cases where it is reasonable to mistrust the provided documentation, a physical audit by a natural person - called auditor - send by e.g. the [OSBA](https://osb-alliance.de/) should be performed. -The CSP of the deployment, which needs such an audit, should grant access to the auditor to the physical infrastructure and should show them all necessary IaaS-Layer configurations, that are needed to verify compliance to this standard. +When reasons exist to mistrust the provided documentation, a physical audit by a natural person - called auditor - sent by e.g. the [OSBA](https://osb-alliance.de/) should be performed. +The CSP of the deployment in need of such an audit should grant access for the auditor to the physical infrastructure and should show them all necessary IaaS-Layer configurations that are needed to verify compliance to this standard. From 82ac3961173b7f7d5fba2075177843ebc5f27399 Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Tue, 2 Sep 2025 15:21:30 +0200 Subject: [PATCH 2/4] One more ... Signed-off-by: Kurt Garloff --- Standards/scs-0121-w1-Availability-Zones-Standard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0121-w1-Availability-Zones-Standard.md b/Standards/scs-0121-w1-Availability-Zones-Standard.md index 645422ca4..9dbde64d7 100644 --- a/Standards/scs-0121-w1-Availability-Zones-Standard.md +++ b/Standards/scs-0121-w1-Availability-Zones-Standard.md @@ -28,7 +28,7 @@ After the initial setup, these requirements typically do not change at all (like Because of this, documentation needs to only be provided in the following cases: 1. When a new deployment with multiple AZs should be tested for compliance initially. -2. When there are physical changes in a deployment, which already provided the documentation: the changes needs to be documented and provided as soon as possible. +2. When there are physical changes in a deployment which already provided the documentation: the changes need to be documented and provided as soon as possible. ### Alternative Documentation From 1d2ca96e8bac28a10627f61bc51465dbb0c00225 Mon Sep 17 00:00:00 2001 From: Marvin Frommhold Date: Tue, 2 Sep 2025 16:01:49 +0200 Subject: [PATCH 3/4] fix yet another typo Signed-off-by: Marvin Frommhold --- Standards/scs-0121-w1-Availability-Zones-Standard.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-0121-w1-Availability-Zones-Standard.md b/Standards/scs-0121-w1-Availability-Zones-Standard.md index 9dbde64d7..655e50db2 100644 --- a/Standards/scs-0121-w1-Availability-Zones-Standard.md +++ b/Standards/scs-0121-w1-Availability-Zones-Standard.md @@ -10,7 +10,7 @@ supplements: The standard will not preclude small deployments and edge deployments, that both will not meet the requirement for being divided into multiple Availability Zones. Thus multiple Availability Zones are not always present. -Somtimes there can just be a single Availability Zone. +Sometimes there can just be a single Availability Zone. Because of that, there will be no automated tests to search for AZs. ## Required Documentation @@ -25,7 +25,7 @@ For each deployment, that uses more than a single Availability Zone, the CSP has 5. The redundancy in core routers within each AZ MUST be documented. After the initial setup, these requirements typically do not change at all (like the fire zones) or are very unlikely to change (like redundant internet connection). -Because of this, documentation needs to only be provided in the following cases: +Because of this, documentation needs to be provided only in the following cases: 1. When a new deployment with multiple AZs should be tested for compliance initially. 2. When there are physical changes in a deployment which already provided the documentation: the changes need to be documented and provided as soon as possible. From 1bce0d6ef90e83b7a958a061c282c0105e97f287 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Matthias=20B=C3=BCchse?= Date: Wed, 10 Sep 2025 10:29:01 +0200 Subject: [PATCH 4/4] Minor rephrasing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Matthias Büchse --- Standards/scs-0121-w1-Availability-Zones-Standard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0121-w1-Availability-Zones-Standard.md b/Standards/scs-0121-w1-Availability-Zones-Standard.md index 655e50db2..9789f5852 100644 --- a/Standards/scs-0121-w1-Availability-Zones-Standard.md +++ b/Standards/scs-0121-w1-Availability-Zones-Standard.md @@ -28,7 +28,7 @@ After the initial setup, these requirements typically do not change at all (like Because of this, documentation needs to be provided only in the following cases: 1. When a new deployment with multiple AZs should be tested for compliance initially. -2. When there are physical changes in a deployment which already provided the documentation: the changes need to be documented and provided as soon as possible. +2. When there are physical changes in a deployment that already provided documentation: the changes need to be documented and provided as soon as possible. ### Alternative Documentation