Apply suggestions from code review

Co-authored-by: Matthias Büchse <[email protected]>
Signed-off-by: kgube <[email protected]>

Author: kgube

Standards/scs-0219-v1-kaas-networking.md

@@ -7,11 +7,11 @@ track: KaaS
 
 ## Introduction
 
-Kubernetes defines a networking model that needs to be implented by a separate CNI plugin.
+Kubernetes defines a networking model that needs to be implemented by a separate CNI plugin.
 Beyond basic connectivity within the cluster, however, there are many networking features that are specified but optional.
 Some of these optional features provide vital functionality, such as the NetworkPolicy API and the Ingress API.
 
-This standard specifies a minimal set of networking features that users can expect in clusters created by an SCS complient KaaS provider.
+This standard specifies a minimal set of networking features that users can expect in clusters created by an SCS-compliant KaaS provider.
 
 ## Terminology
 
@@ -28,17 +28,17 @@ The following terms are used throughout this document:
 ## Motivation
 
 KaaS providers will typically support aditional networking functionality beyond basic Kubernetes networking.
-The specific range features depends on the used CNI plugin, but may also be extended by additional operators.
+The specific range of features depends on the used CNI plugin, but may also be extended by additional operators.
 Users may expect certain optional functionality, so we should define a baseline feature set that has to be available in an SCS-compliant KaaS cluster.
 
 ## Design Considerations
 
-The Kubernetes API is arbitrary extensible.
+The Kubernetes API can be extended arbitrarily.
 Many CNI plugins will define custom resources to enable functionality that is not covered in the official [API specification](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/).
 Sometimes they will even reuse names from different API groups, such as `NetworkPolicy`, which exists in the basic `networking.k8s.io/v1` API, but also in `projectcalico.org/v3`.
 
 To avoid any ambiguity, we should therefore be explicit about the API groups and versions of resources.
-We should also avoid mandating third party API extensions, to avoid dependencies on specific third party software and keep the standard as generic as possible.
+We should also avoid mandating third-party API extensions, to avoid dependencies on specific third-party software and keep the standard as generic as possible.
 
 ### Options considered
 
@@ -49,7 +49,7 @@ The policy rules can filter based on port and address ranges, but also on Kubern
 They must be implemented by the CNI plugin, and though they are widely supported, they are still technically optional, and there are some lightweight networking plugins, such as Flannel, that are not enforcing them.
 
 Nonetheless, network policies are widely used and most users will expect them in a managed Kubernetes cluster.
-The wide support among CNI plugins makes them a good target for SCS standardization.
+The wide, but varying support among CNI plugins makes them a good target for SCS standardization.
 
 #### Default Network Policies in Namespaces
 
@@ -67,7 +67,7 @@ CSP-provided network policies should thus only be viewed as a safety default, an
 An alternative to automatically created default network policies are API extensions that allow cluster-wide networking rules.
 Some CNI plugins have implemented such extensions, e.g. Calico's `GlobalNetworkPolicy` and Cilium's `CiliumClusterwideNetworkPolicy`.
 
-The Kubernetes Network Policy Special Interest Group is currently working on an [official API extension](https://network-policy-api.sigs.k8s.io/api-overview/) to cover this functionality.
+The Kubernetes Network Special Interest Group is currently working on an [official API extension](https://network-policy-api.sigs.k8s.io/api-overview/) to cover this functionality.
 This API extension introduces the new `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` resources, which represent cluster-wide network policies with respectively higher or lower precedence than namespaced network policies.
 
 This API is also a good candidate for standardization because it consolidates a number of vendor-specific workarounds to limitations of the NetworkPolicy API.

Standards/scs-0219-w1-kaas-networking.md

@@ -8,8 +8,8 @@ supplements:
 ---
 ## List of compliant CNI Plugins
 
-The Kubernetes Network Policy SIG maintains a [list of work-in-progress implementations](https://network-policy-api.sigs.k8s.io/implementations/) of the AdminNetworkPolicy and BaselineAdminNetworkPolicy resources.
-Besides their own validation implementation of [kube-network-policies](https://github.com/kubernetes-sigs/kube-network-policies), at the time of writing they list the following CNI plugins:
+The Kubernetes Network Policy API working group maintains a [list of work-in-progress implementations](https://network-policy-api.sigs.k8s.io/implementations/) of the AdminNetworkPolicy and BaselineAdminNetworkPolicy resources.
+Besides their own proof-of-concept implementation of [kube-network-policies](https://github.com/kubernetes-sigs/kube-network-policies), at the time of writing they list the following CNI plugins:
 
 - [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)
 - [Antrea](https://github.com/antrea-io/antrea/)