rename k8s.io/tcp to k8s.io/raw and move it to followup work

Author: LiorLieberman

keps/sig-network/3726-standard-application-protocols/README.md

@@ -50,7 +50,7 @@ tags, and then generate with `hack/update-toc.sh`.
 <!--
 **ACTION REQUIRED:** In order to merge code into a release, there must be an
 issue in [kubernetes/enhancements] referencing this KEP and targeting a release
-milestone **before the [Enhancement Freeze](https://git.k8s.io/sig-release/releases)
+milestone **before the [Enhancement Freeze](https://git.kubernetes.io/sig-release/releases)
 of the targeted release**.
 
 For enhancements that make changes to code or processes/procedures in core
@@ -83,9 +83,9 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 -->
 
 [kubernetes.io]: https://kubernetes.io/
-[kubernetes/enhancements]: https://git.k8s.io/enhancements
-[kubernetes/kubernetes]: https://git.k8s.io/kubernetes
-[kubernetes/website]: https://git.k8s.io/website
+[kubernetes/enhancements]: https://git.kubernetes.io/enhancements
+[kubernetes/kubernetes]: https://git.kubernetes.io/kubernetes
+[kubernetes/website]: https://git.kubernetes.io/website
 
 ## Summary
 
@@ -139,18 +139,17 @@ The [documentation](https://kubernetes.io/docs/concepts/services-networking/serv
 
 This KEP proposes to declare standard Kubernetes protocol names for common protocols that are not IANA standard service names.
 
-Those common protocols will be well defined strings prefixed with ‘k8s.io’. 
-`k8s.io/h2c` as an example.
+Those common protocols will be well defined strings prefixed with ‘kubernetes.io’. 
+`kubernetes.io/h2c` as an example.
 
 ### New Standard Protocols
-- 'k8s.io/http2'
-- 'k8s.io/grpc'
-- 'k8s.io/tcp'
+- 'kubernetes.io/h2c'
+- 'kubernetes.io/grpc'
 
 ### Risks and Mitigations
 
 There are no real “risks”, primary concerns are:
-1. End users will not migrate to `k8s.io/<>` values
+1. End users will not migrate to `kubernetes.io/<>` values
 2. It will take long time to implementations align with the new standards
 3. We have no easy way to monitor who is aligned and who is not
 
@@ -168,21 +167,19 @@ type ServicePort struct {
   ... 
   ...
 
-  // Used as a hint for implementations to
-  // configure the protocol used between the
-  // implementation and the application it exposes.
-  // This field follows standard Kubernetes label syntax.
-  // Valid values are either:
-  //
-  // * Un-prefixed protocol names - reserved for IANA standard service names (as per
-  // RFC-6335 and https://www.iana.org/assignments/service-names).
-  //
-  // * Kubernetes standard names:
-  //   * 'k8s.io/http2' - http2 over cleartext, aka 'h2c'. https://www.rfc-editor.org/rfc/rfc7540
-  //   * 'k8s.io/grpc' - grpc traffic - see https://github.com/grpc/grpc/blob/v1.51.1/doc/PROTOCOL-HTTP2.md
-  //   * 'k8s.io/tcp' - plain tcp traffic
-  //
-  // * Other protocols should use prefixed names such as
+  // The application protocol for this port.
+	// This is used as a hint for implementations to offer richer behavior for protocols that they understand.
+	// This field follows standard Kubernetes label syntax.
+	// Valid values are either:
+	//
+	// * Un-prefixed protocol names - reserved for IANA standard service names (as per
+	// RFC-6335 and https://www.iana.org/assignments/service-names).
+	//
+	// * Kubernetes-defined prefixed names:
+	//   * 'kubernetes.io/h2c' - HTTP/2 over cleartext as described in https://www.rfc-editor.org/rfc/rfc7540
+	//   * 'kubernetes.io/grpc' - gRPC over HTTP/2 as described in https://github.com/grpc/grpc/blob/v1.51.1/doc/PROTOCOL-HTTP2.md
+	//
+	// * Other protocols should use implementation-defined prefixed names such as
   // mycompany.com/my-custom-protocol.
   // +optional
   AppProtocol *string
@@ -200,18 +197,21 @@ In order to be included in the collection, a new protocol must:
 
 <<[UNRESOLVED sig-network ]>>
 
-if we require two implementations to support a protocol before we include it in the standard collection (i.e k8s.io prefixed collection) we create a situation where we force them to support their own domain prefixed values and k8s.io-prefixed values, have their users migrate to the k8s.io values once they are included, and also the k8s.io ones might end up not be quite the same definition as the implementation specific ones (as we see in the GKE & Istio example).
+if we require two implementations to support a protocol before we include it in the standard collection (i.e kubernetes.io prefixed collection) we create a situation where we force them to support their own domain prefixed values and kubernetes.io-prefixed values, have their users migrate to the kubernetes.io values once they are included, and also the kubernetes.io ones might end up not be quite the same definition as the implementation specific ones (as we see in the GKE & Istio example).
 
 The proposed followup work might address this problem also when we turn the field into a list
 
 <<[/UNRESOLVED]>>
 
 
 ### Followup work
-To support implementations interoperability with different domain prefixed protocols (or a mix domain prefixed and non prefixed protocol) for the same port we need to turn `AppProtocol` to a list.
+- To support implementations interoperability with different domain prefixed protocols (or a mix domain prefixed and non prefixed protocol) for the same port we need to turn `AppProtocol` to a list.
 
 It is likely to be an API change but design details TBD.
 
+- Some implementations are trying to guess the application protocol in absence of `appProtocol`. We should consider adding a new protocol like `kubernetes.io/raw` to the collection that would instructs implementations to process requests as raw.
+We need to look at combination of `appProtocol: kubernetes.io/raw` and the different supported port protocols (TCP, UDP, SCTP).  
+
 ### Documentation change
 
 [kubernetes website](https://github.com/kubernetes/website/blob/main/content/en/docs/concepts/services-networking/service.md#application-protocol) will be changed accordingly
@@ -282,7 +282,7 @@ N/A
 
 ## Drawbacks
 
-* The collection of the standard protocols can become stale fairly quick when new protocols are implemented before we decide to declare them as part of k8s.io common collection. That can lead to a the current state again where implementations already implement support without a prefix (although they should not) OR with a domain prefix.
+* The collection of the standard protocols can become stale fairly quick when new protocols are implemented before we decide to declare them as part of kubernetes.io common collection. That can lead to a the current state again where implementations already implement support without a prefix (although they should not) OR with a domain prefix.
 
 
 ## Alternatives

keps/sig-network/3726-standard-application-protocols/kep.yaml

@@ -4,7 +4,7 @@ authors:
   - "@LiorLieberman"
 owning-sig: sig-network
 
-status: provisional
+status: implementable
 creation-date: 2023-01-11
 reviewers:
   - "@aojea"