Fix minor inconsistencies in documentation

npeps/npep-133-fqdn-egress-selector.md

@@ -16,14 +16,14 @@ Names](https://www.wikipedia.org/wiki/Fully_qualified_domain_name) (FQDNs).
   (for example `kubernetes.io`).
 * Support basic wildcard matching capabilities when specifying FQDNs (for
   example `*.cloud-provider.io`)
-* Currently only `ALLOW` type rules are proposed.
-  * Safely enforcing `DENY` rules based on FQDN selectors is difficult as there
+* Currently only `Accept` type rules are proposed.
+  * Safely enforcing `Deny` rules based on FQDN selectors is difficult as there
     is no guarantee a Network Policy plugin is aware of all IPs backing a FQDN
     policy. If a Network Policy plugin has incomplete information, it may
     accidentally allow traffic to an IP belonging to a denied domain. This would
     constitute a security breach.
 
-    By contrast, `ALLOW` rules, which may also have an incomplete list of IPs,
+    By contrast, `Accept` rules, which may also have an incomplete list of IPs,
     would not create a security breach. In case of incomplete information, valid
     traffic would be dropped as the plugin believes the destination IP does not
     belong to the domain. While this is definitely undesirable, it is at least
@@ -179,8 +179,8 @@ spec:
 
 There are a couple ways to maintain an allowlist:
 
-This example, includes the DENY rule in the same ANP object. It's also possible
-to use another ANP object with a lower priority (e.g. `100` in this example):
+This example, includes the Deny rule in the same CNP object. It's also possible
+to use another CNP object with a lower priority (e.g. `100` in this example):
 ```yaml
 apiVersion: policy.networking.k8s.io/v1alpha1
 kind: ClusterNetworkPolicy
@@ -442,4 +442,4 @@ perform subsequent lookups to resolve CNAMEs returned for a particular query. In
 the above example, querying for `www.kubernetes.io.` returned a CNAME record for
 `kubernetes.io.`. When CNAME chasing is enabled, the DNS server will
 automatically resolve `kubernetes.io.` and return both records as the DNS
-response.
+response.

site-src/api-overview.md

@@ -8,7 +8,7 @@ personas, sometimes creating a complex web of objects to be maintained. In
 contrast, each resource in the Network Policy API is designed to be used by a
 specific persona.
 
-With the advent of the ClusterNetworkPolicy resource Cluster Admins will now have 
+With the advent of the ClusterNetworkPolicy resource Cluster Admins will now have
 the ability to apply policy globally with only a few simple policy objects.
 
 ## Roles and personas
@@ -60,13 +60,13 @@ Policy tiers are evaluated in the following order:
 
 ClusterNetworkPolicy can use 2 of these tiers: `Admin` and `Baseline`.
 
-The `Admin` tier will help administrators set strict security rules for the cluster, 
-i.e. a developer CANNOT override these rules by creating NetworkPolicies that apply 
+The `Admin` tier will help administrators set strict security rules for the cluster,
+i.e. a developer CANNOT override these rules by creating NetworkPolicies that apply
 to the same workloads as the ClusterNetworkPolicy.
 
-The `Baseline` tier will allow administrators to set baseline security rules that 
-describe default connectivity for cluster workloads, which CAN be overridden by 
-developer NetworkPolicies if needed. 
+The `Baseline` tier will allow administrators to set baseline security rules that
+describe default connectivity for cluster workloads, which CAN be overridden by
+developer NetworkPolicies if needed.
 The major use case for `Baseline` tier is the ability to flip the [default security stance of the
 cluster](user-stories.md#story-5-cluster-wide-default-guardrails).
 
@@ -101,32 +101,32 @@ CoreDNS for example). This traffic should not be blocked when developers apply
 NetworkPolicy to their Namespaces which isolates the workloads.
 
 ClusterNetworkPolicy `Pass` rules in the `Admin` tier allow an admin to delegate security posture for
-certain traffic to the Namespace owners by overriding any lower precedence Allow
+certain traffic to the Namespace owners by overriding any lower precedence Accept
 or Deny rules. For example, intra-namespace traffic management can be delegated to namespace
 admins explicitly with the use of `Pass` rules. More specifically traffic selected by a `Pass` rule
 will skip any lower precedence `Admin` tier rules and proceed to be evaluated by `NetworkPolicy` and
-`Baseline` tier policies. When the `Pass` action is matched at the `Admin` tier, `NetworkPolicy` will 
+`Baseline` tier policies. When the `Pass` action is matched at the `Admin` tier, `NetworkPolicy` will
 apply next or if there is no `NetworkPolicy` match, `Baseline` policies will be evaluated.
 
-### Priorities 
+### Priorities
 
-Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster 
-Admins to express direct and intentional ordering between various CNP Objects.  
-The `Priority` field in the CNP spec is defined as a non-negative integer value 
-where rules with lower priority values have higher precedence, and are checked 
+Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster
+Admins to express direct and intentional ordering between various CNP Objects.
+The `Priority` field in the CNP spec is defined as a non-negative integer value
+where rules with lower priority values have higher precedence, and are checked
 before policies with higher priority values in the same tier.
 
-### Rules 
+### Rules
 
-Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow 
-along with the associated Action that should occur. In each `gress` rule the user 
+Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow
+along with the associated Action that should occur. In each `gress` rule the user
 should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`.
 Optionally the user may also define select `Protocols` to filter traffic on and also
 a name for each rule to make management and reporting easier for Admins.
 
 Within the `Protocols` array, `TCP`, `UDP`, or `SCTP` protocols can be specified, each with an
-optional `DestinationPort`. The `DestinationPort` can be a single `Number` or a `Range`
-with a `Start` and `End`. If `DestinationPort` is omitted, all ports for the specified
+optional `destinationPort`. The `destinationPort` can be a single `number` or a `range`
+with a `start` and `end`. If `destinationPort` is omitted, all ports for the specified
 protocol match.
 
 Alternatively, `DestinationNamedPort` can be used to target a port by name. A named port is
@@ -135,10 +135,10 @@ a string to the name field alongside the containerPort. Existing named ports can
 inspecting the resource's YAML under `spec.containers[].ports` or by running `kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].ports[*].name}'`. Using a name instead of a number allows the ClusterNetworkPolicy to remain valid even
 if the container’s underlying port number is updated.
 
-### Status 
+### Status
 
-For `v1alpha2` of this API the ANP status field is simply defined as a list of 
+For `v1alpha2` of this API the CNP status field is simply defined as a list of
 [`metav1.condition`](https://github.com/kubernetes/apimachinery/blob/v0.25.0/pkg/apis/meta/v1/types.go#L1464)s. Currently there are no rules as to what these conditions should display,
-and it is up to each implementation to report what they see fit. For further 
-API iterations the community may consider standardizing these conditions based on 
+and it is up to each implementation to report what they see fit. For further
+API iterations the community may consider standardizing these conditions based on
 the usefulness they provide for various implementors.

site-src/npeps/npep-133.md

@@ -16,39 +16,39 @@ Names](https://www.wikipedia.org/wiki/Fully_qualified_domain_name) (FQDNs).
   (for example `kubernetes.io`).
 * Support basic wildcard matching capabilities when specifying FQDNs (for
   example `*.cloud-provider.io`)
-* Currently only `ALLOW` type rules are proposed.
+* Currently only `Accept` type rules are proposed.
   * Safely enforcing `DENY` rules based on FQDN selectors is difficult as there
     is no guarantee a Network Policy plugin is aware of all IPs backing a FQDN
     policy. If a Network Policy plugin has incomplete information, it may
     accidentally allow traffic to an IP belonging to a denied domain. This would
     constitute a security breach.
 
-    By contrast, `ALLOW` rules, which may also have an incomplete list of IPs,
+    By contrast, `Accept` rules, which may also have an incomplete list of IPs,
     would not create a security breach. In case of incomplete information, valid
     traffic would be dropped as the plugin believes the destination IP does not
     belong to the domain. While this is definitely undesirable, it is at least
     not an unsafe failure.
 
-* Currently only AdminNetworkPolicy is the intended scope for this proposal.
+* Currently only ClusterNetworkPolicy is the intended scope for this proposal.
   * Since Kubernetes NetworkPolicy does not have a FQDN selector, adding this
-    capability to BaselineAdminNetworkPolicy could result in writing baseline
-    rules that can't be replicated by an overriding NetworkPolicy. For example,
-    if BANP allows traffic to `example.io`, but the namespace admin installs a
-    Kubernetes Network Policy, the namespace admin has no way to replicate the
-    `example.io` selector using just Kubernetes Network Policies.
+    capability to Baseline tier of ClusterNetworkPolicy could result in writing
+    baseline rules that can't be replicated by an overriding NetworkPolicy. For
+    example, if CNP allows traffic to `example.io`, but the namespace admin
+    installs a Kubernetes Network Policy, the namespace admin has no way to
+    replicate the `example.io` selector using just Kubernetes Network Policies.
 
 ## Non-Goals
 
 * This enhancement does not include a FQDN selector for allowing ingress
   traffic.
 * This enhancement only describes enhancements to the existing L4 filtering as
-  provided by AdminNetworkPolicy. It does not propose any new L7 matching or
+  provided by ClusterNetworkPolicy. It does not propose any new L7 matching or
   filtering capabilities, like matching HTTP traffic or URL paths.
   * This selector should not control what DNS records are resolvable from a
     particular workload.
 * This enhancement does not provide a mechanism for selecting in-cluster
   endpoints using FQDNs. To select Pods, Nodes, or the API Server,
-  AdminNetworkPolicy has other more specific selectors.
+  ClusterNetworkPolicy has other more specific selectors.
   * Using the FQDN selector to refer to other Kubernetes endpoints, while not
     explicitly disallowed, is not defined by this spec and left up to individual
     providers. Trying to allow traffic to the following domains is NOT