From fb1a684a12ad17710c049179423634298ea1c466 Mon Sep 17 00:00:00 2001 From: Nick Young Date: Mon, 5 Dec 2022 22:40:16 +0000 Subject: [PATCH] Fix PR comments Signed-off-by: Nick Young --- site-src/geps/gep-713.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/site-src/geps/gep-713.md b/site-src/geps/gep-713.md index 0292070dc7..d829d9d06b 100644 --- a/site-src/geps/gep-713.md +++ b/site-src/geps/gep-713.md @@ -6,12 +6,12 @@ ## TLDR This GEP aims to standardize attachment of one Kubernetes object to another in -Gateway API by establishing a pattern which defines how metaresources such as +Gateway API by establishing a pattern which defines how _metaresources_ such as `Policy` API types can have their relevant effects applied to network traffic. -Metaresources are a type of object that _augments_ the behavior of an object -in a standard way. +_Metaresources_ are a type of object that _augments_ the behavior of an object +in a standard way. ReferenceGrant is an example of this general type of metaresource. -"Policy Attachment" is a specific type of metaresource that controls how policy +"Policy Attachment" is a specific type of _metaresource_ that controls how policy can flow _across_ multiple objects in a hierarchy. Individual policy APIs (e.g. `TimeoutPolicy`, `RetryPolicy`, etc) must include a common `TargetRef` field in their specification to identify how and where to @@ -50,16 +50,16 @@ portable. ## Background and concepts -One of the things we’ve found when making Gateway API is that we often need to be -able to represent information _about_ objects _outside of_ those objects. That is, -sometimes we need ways to be able to affect how an object is interpreted in the -API, without representing the description of those effects inside the spec of the -object. +When designing Gateway API, one of the things we’ve found is that we often need to be +able change the behavior of objects without being able to make changes to the spec +of those objects. Sometimes, this is because we can’t change the spec of the object +to hold the information we need ( ReferenceGrant, from GEP-709, affecting Secrets +and Services is an example), and sometimes it’s because we want the behavior change +to flow across multiple objects (this is what Policy Attachment is for). -Sometimes, this is because we can’t change the spec of the object to hold the -information we need ( ReferenceGrant, from GEP-709, is an example), and sometimes -it’s because we want the information we need to flow across multiple objects -(this is what Policy Attachment is for). +To put this another way, sometimes we need ways to be able to affect how an object +is interpreted in the API, without representing the description of those effects +inside the spec of the object. This document describes the ways we design objects to meet these two use cases, and why you might choose one or the other.