From 3abcca7f88999e9426d6a60ef44fc86c7395033c Mon Sep 17 00:00:00 2001 From: Nick Young Date: Mon, 9 Oct 2023 11:00:19 +0000 Subject: [PATCH] Fix further PR comments Signed-off-by: Nick Young --- apis/v1beta1/gateway_types.go | 34 +++- .../gateway.networking.k8s.io_gateways.yaml | 174 ++++++++++-------- .../gateway.networking.k8s.io_gateways.yaml | 174 ++++++++++-------- 3 files changed, 216 insertions(+), 166 deletions(-) diff --git a/apis/v1beta1/gateway_types.go b/apis/v1beta1/gateway_types.go index e58b6b5978..4882a4d244 100644 --- a/apis/v1beta1/gateway_types.go +++ b/apis/v1beta1/gateway_types.go @@ -79,13 +79,18 @@ type GatewaySpec struct { // Practically, this means that each listener in a set MUST have a unique // combination of Port, Protocol, and, if supported by the protocol, Hostname. // - // Some combinations of port, protocol, and TLS settings are are considered - // Core support and MUST be supported by implementations if they support the - // associated Route type: + // Some combinations of port, protocol, and TLS settings are considered + // Core support and MUST be supported by implementations based on their + // targeted conformance profile: + // + // HTTP Profile // // 1. HTTPRoute, Port: 80, Protocol: HTTP // 2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided - // 3. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough + // + // TLS Profile + // + // 1. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough // // "Distinct" Listeners have the following property: // @@ -135,12 +140,21 @@ type GatewaySpec struct { // Listeners are Conflicted, and the implementation MUST set the "Conflicted" // condition in the Listener Status to "True". // - // Implementations MAY choose to accept a Gateway with Conflicted - // Listeners if they accept a partial Listener set that contains no - // Conflicted Listeners. They MUST set a "ListenersNotValid" condition - // the Gateway Status when the Gateway contains Conflicted Listeners - // whether or not they accept the Gateway. That Condition SHOULD clearly - // indicate in the Message which Listeners are conflicted. + // Implementations MAY choose to accept a Gateway with some Conflicted + // Listeners only if they only accept the partial Listener set that contains + // no Conflicted Listeners. To put this another way, implementations may + // accept a partial Listener set only if they throw out *all* the conflicting + // Listeners. No picking one of the conflicting listeners as the winner. + // This also means that the Gateway must have at least one non-conflicting + // Listener in this case, otherwise it violates the requirement that at + // least one Listener must be present. + // + // The implementation MUST set a "ListenersNotValid" condition on the + // Gateway Status when the Gateway contains Conflicted Listeners whether or + // not they accept the Gateway. That Condition SHOULD clearly + // indicate in the Message which Listeners are conflicted, and which are + // Accepted. Additionally, the Listener status for those listeners SHOULD + // indicate which Listeners are conflicted and not Accepted. // // A Gateway's Listeners are considered "compatible" if: // diff --git a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml index 7dd5c19453..28930d64a6 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml @@ -182,27 +182,28 @@ spec: _also_ apply in that case). \n Practically, this means that each listener in a set MUST have a unique combination of Port, Protocol, and, if supported by the protocol, Hostname. \n Some combinations - of port, protocol, and TLS settings are are considered Core support - and MUST be supported by implementations if they support the associated - Route type: \n 1. HTTPRoute, Port: 80, Protocol: HTTP 2. HTTPRoute, - Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided - 3. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough \n - \"Distinct\" Listeners have the following property: \n The implementation - can match inbound requests to a single distinct Listener. When multiple - Listeners share values for fields (for example, two Listeners with - the same Port value), the implementation can match requests to only - one of the Listeners using other Listener fields. \n For example, - the following Listener scenarios are distinct: \n 1. Multiple Listeners - with the same Port that all use the \"HTTP\" Protocol that all have - unique Hostname values. 2. Multiple Listeners with the same Port - that use either the \"HTTPS\" or \"TLS\" Protocol that all have - unique Hostname values. 3. A mixture of \"TCP\" and \"UDP\" Protocol - Listeners, where no Listener with the same Protocol has the same - Port value. \n Some fields in the Listener struct have possible - values that affect whether the Listener is distinct. Hostname is - particularly relevant for HTTP or HTTPS protocols. \n When using - the Hostname value to select between same-Port, same-Protocol Listeners, - the Hostname value must be different on each Listener for the Listener + of port, protocol, and TLS settings are considered Core support + and MUST be supported by implementations based on their targeted + conformance profile: \n HTTP Profile \n 1. HTTPRoute, Port: 80, + Protocol: HTTP 2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: + Terminate, TLS keypair provided \n TLS Profile \n 1. TLSRoute, Port: + 443, Protocol: TLS, TLS Mode: Passthrough \n \"Distinct\" Listeners + have the following property: \n The implementation can match inbound + requests to a single distinct Listener. When multiple Listeners + share values for fields (for example, two Listeners with the same + Port value), the implementation can match requests to only one of + the Listeners using other Listener fields. \n For example, the following + Listener scenarios are distinct: \n 1. Multiple Listeners with the + same Port that all use the \"HTTP\" Protocol that all have unique + Hostname values. 2. Multiple Listeners with the same Port that use + either the \"HTTPS\" or \"TLS\" Protocol that all have unique Hostname + values. 3. A mixture of \"TCP\" and \"UDP\" Protocol Listeners, + where no Listener with the same Protocol has the same Port value. + \n Some fields in the Listener struct have possible values that + affect whether the Listener is distinct. Hostname is particularly + relevant for HTTP or HTTPS protocols. \n When using the Hostname + value to select between same-Port, same-Protocol Listeners, the + Hostname value must be different on each Listener for the Listener to be distinct. \n When the Listeners are distinct based on Hostname, inbound request hostnames MUST match from the most specific to least specific Hostname values to choose the correct Listener and its @@ -222,25 +223,33 @@ spec: that are not distinct, then those Listeners are Conflicted, and the implementation MUST set the \"Conflicted\" condition in the Listener Status to \"True\". \n Implementations MAY choose to accept - a Gateway with Conflicted Listeners if they accept a partial Listener - set that contains no Conflicted Listeners. They MUST set a \"ListenersNotValid\" - condition the Gateway Status when the Gateway contains Conflicted + a Gateway with some Conflicted Listeners only if they only accept + the partial Listener set that contains no Conflicted Listeners. + To put this another way, implementations may accept a partial Listener + set only if they throw out *all* the conflicting Listeners. No picking + one of the conflicting listeners as the winner. This also means + that the Gateway must have at least one non-conflicting Listener + in this case, otherwise it violates the requirement that at least + one Listener must be present. \n The implementation MUST set a \"ListenersNotValid\" + condition on the Gateway Status when the Gateway contains Conflicted Listeners whether or not they accept the Gateway. That Condition - SHOULD clearly indicate in the Message which Listeners are conflicted. - \n A Gateway's Listeners are considered \"compatible\" if: \n 1. - They are distinct. 2. The implementation can serve them in compliance - with the Addresses requirement that all Listeners are available - on all assigned addresses. \n Compatible combinations in Extended - support are expected to vary across implementations. A combination - that is compatible for one implementation may not be compatible - for another. \n For example, an implementation that cannot serve - both TCP and UDP listeners on the same address, or cannot mix HTTPS - and generic TLS listens on the same port would not consider those - cases compatible, even though they are distinct. \n Note that requests - SHOULD match at most one Listener. For example, if Listeners are - defined for \"foo.example.com\" and \"*.example.com\", a request - to \"foo.example.com\" SHOULD only be routed using routes attached - to the \"foo.example.com\" Listener (and not the \"*.example.com\" + SHOULD clearly indicate in the Message which Listeners are conflicted, + and which are Accepted. Additionally, the Listener status for those + listeners SHOULD indicate which Listeners are conflicted and not + Accepted. \n A Gateway's Listeners are considered \"compatible\" + if: \n 1. They are distinct. 2. The implementation can serve them + in compliance with the Addresses requirement that all Listeners + are available on all assigned addresses. \n Compatible combinations + in Extended support are expected to vary across implementations. + A combination that is compatible for one implementation may not + be compatible for another. \n For example, an implementation that + cannot serve both TCP and UDP listeners on the same address, or + cannot mix HTTPS and generic TLS listens on the same port would + not consider those cases compatible, even though they are distinct. + \n Note that requests SHOULD match at most one Listener. For example, + if Listeners are defined for \"foo.example.com\" and \"*.example.com\", + a request to \"foo.example.com\" SHOULD only be routed using routes + attached to the \"foo.example.com\" Listener (and not the \"*.example.com\" Listener). This concept is known as \"Listener Isolation\". Implementations that do not support Listener Isolation MUST clearly document this. \n Implementations MAY merge separate Gateways onto a single set @@ -1061,27 +1070,28 @@ spec: _also_ apply in that case). \n Practically, this means that each listener in a set MUST have a unique combination of Port, Protocol, and, if supported by the protocol, Hostname. \n Some combinations - of port, protocol, and TLS settings are are considered Core support - and MUST be supported by implementations if they support the associated - Route type: \n 1. HTTPRoute, Port: 80, Protocol: HTTP 2. HTTPRoute, - Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided - 3. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough \n - \"Distinct\" Listeners have the following property: \n The implementation - can match inbound requests to a single distinct Listener. When multiple - Listeners share values for fields (for example, two Listeners with - the same Port value), the implementation can match requests to only - one of the Listeners using other Listener fields. \n For example, - the following Listener scenarios are distinct: \n 1. Multiple Listeners - with the same Port that all use the \"HTTP\" Protocol that all have - unique Hostname values. 2. Multiple Listeners with the same Port - that use either the \"HTTPS\" or \"TLS\" Protocol that all have - unique Hostname values. 3. A mixture of \"TCP\" and \"UDP\" Protocol - Listeners, where no Listener with the same Protocol has the same - Port value. \n Some fields in the Listener struct have possible - values that affect whether the Listener is distinct. Hostname is - particularly relevant for HTTP or HTTPS protocols. \n When using - the Hostname value to select between same-Port, same-Protocol Listeners, - the Hostname value must be different on each Listener for the Listener + of port, protocol, and TLS settings are considered Core support + and MUST be supported by implementations based on their targeted + conformance profile: \n HTTP Profile \n 1. HTTPRoute, Port: 80, + Protocol: HTTP 2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: + Terminate, TLS keypair provided \n TLS Profile \n 1. TLSRoute, Port: + 443, Protocol: TLS, TLS Mode: Passthrough \n \"Distinct\" Listeners + have the following property: \n The implementation can match inbound + requests to a single distinct Listener. When multiple Listeners + share values for fields (for example, two Listeners with the same + Port value), the implementation can match requests to only one of + the Listeners using other Listener fields. \n For example, the following + Listener scenarios are distinct: \n 1. Multiple Listeners with the + same Port that all use the \"HTTP\" Protocol that all have unique + Hostname values. 2. Multiple Listeners with the same Port that use + either the \"HTTPS\" or \"TLS\" Protocol that all have unique Hostname + values. 3. A mixture of \"TCP\" and \"UDP\" Protocol Listeners, + where no Listener with the same Protocol has the same Port value. + \n Some fields in the Listener struct have possible values that + affect whether the Listener is distinct. Hostname is particularly + relevant for HTTP or HTTPS protocols. \n When using the Hostname + value to select between same-Port, same-Protocol Listeners, the + Hostname value must be different on each Listener for the Listener to be distinct. \n When the Listeners are distinct based on Hostname, inbound request hostnames MUST match from the most specific to least specific Hostname values to choose the correct Listener and its @@ -1101,25 +1111,33 @@ spec: that are not distinct, then those Listeners are Conflicted, and the implementation MUST set the \"Conflicted\" condition in the Listener Status to \"True\". \n Implementations MAY choose to accept - a Gateway with Conflicted Listeners if they accept a partial Listener - set that contains no Conflicted Listeners. They MUST set a \"ListenersNotValid\" - condition the Gateway Status when the Gateway contains Conflicted + a Gateway with some Conflicted Listeners only if they only accept + the partial Listener set that contains no Conflicted Listeners. + To put this another way, implementations may accept a partial Listener + set only if they throw out *all* the conflicting Listeners. No picking + one of the conflicting listeners as the winner. This also means + that the Gateway must have at least one non-conflicting Listener + in this case, otherwise it violates the requirement that at least + one Listener must be present. \n The implementation MUST set a \"ListenersNotValid\" + condition on the Gateway Status when the Gateway contains Conflicted Listeners whether or not they accept the Gateway. That Condition - SHOULD clearly indicate in the Message which Listeners are conflicted. - \n A Gateway's Listeners are considered \"compatible\" if: \n 1. - They are distinct. 2. The implementation can serve them in compliance - with the Addresses requirement that all Listeners are available - on all assigned addresses. \n Compatible combinations in Extended - support are expected to vary across implementations. A combination - that is compatible for one implementation may not be compatible - for another. \n For example, an implementation that cannot serve - both TCP and UDP listeners on the same address, or cannot mix HTTPS - and generic TLS listens on the same port would not consider those - cases compatible, even though they are distinct. \n Note that requests - SHOULD match at most one Listener. For example, if Listeners are - defined for \"foo.example.com\" and \"*.example.com\", a request - to \"foo.example.com\" SHOULD only be routed using routes attached - to the \"foo.example.com\" Listener (and not the \"*.example.com\" + SHOULD clearly indicate in the Message which Listeners are conflicted, + and which are Accepted. Additionally, the Listener status for those + listeners SHOULD indicate which Listeners are conflicted and not + Accepted. \n A Gateway's Listeners are considered \"compatible\" + if: \n 1. They are distinct. 2. The implementation can serve them + in compliance with the Addresses requirement that all Listeners + are available on all assigned addresses. \n Compatible combinations + in Extended support are expected to vary across implementations. + A combination that is compatible for one implementation may not + be compatible for another. \n For example, an implementation that + cannot serve both TCP and UDP listeners on the same address, or + cannot mix HTTPS and generic TLS listens on the same port would + not consider those cases compatible, even though they are distinct. + \n Note that requests SHOULD match at most one Listener. For example, + if Listeners are defined for \"foo.example.com\" and \"*.example.com\", + a request to \"foo.example.com\" SHOULD only be routed using routes + attached to the \"foo.example.com\" Listener (and not the \"*.example.com\" Listener). This concept is known as \"Listener Isolation\". Implementations that do not support Listener Isolation MUST clearly document this. \n Implementations MAY merge separate Gateways onto a single set diff --git a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml index 6c2d129429..1ca74ff291 100644 --- a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml @@ -139,27 +139,28 @@ spec: _also_ apply in that case). \n Practically, this means that each listener in a set MUST have a unique combination of Port, Protocol, and, if supported by the protocol, Hostname. \n Some combinations - of port, protocol, and TLS settings are are considered Core support - and MUST be supported by implementations if they support the associated - Route type: \n 1. HTTPRoute, Port: 80, Protocol: HTTP 2. HTTPRoute, - Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided - 3. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough \n - \"Distinct\" Listeners have the following property: \n The implementation - can match inbound requests to a single distinct Listener. When multiple - Listeners share values for fields (for example, two Listeners with - the same Port value), the implementation can match requests to only - one of the Listeners using other Listener fields. \n For example, - the following Listener scenarios are distinct: \n 1. Multiple Listeners - with the same Port that all use the \"HTTP\" Protocol that all have - unique Hostname values. 2. Multiple Listeners with the same Port - that use either the \"HTTPS\" or \"TLS\" Protocol that all have - unique Hostname values. 3. A mixture of \"TCP\" and \"UDP\" Protocol - Listeners, where no Listener with the same Protocol has the same - Port value. \n Some fields in the Listener struct have possible - values that affect whether the Listener is distinct. Hostname is - particularly relevant for HTTP or HTTPS protocols. \n When using - the Hostname value to select between same-Port, same-Protocol Listeners, - the Hostname value must be different on each Listener for the Listener + of port, protocol, and TLS settings are considered Core support + and MUST be supported by implementations based on their targeted + conformance profile: \n HTTP Profile \n 1. HTTPRoute, Port: 80, + Protocol: HTTP 2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: + Terminate, TLS keypair provided \n TLS Profile \n 1. TLSRoute, Port: + 443, Protocol: TLS, TLS Mode: Passthrough \n \"Distinct\" Listeners + have the following property: \n The implementation can match inbound + requests to a single distinct Listener. When multiple Listeners + share values for fields (for example, two Listeners with the same + Port value), the implementation can match requests to only one of + the Listeners using other Listener fields. \n For example, the following + Listener scenarios are distinct: \n 1. Multiple Listeners with the + same Port that all use the \"HTTP\" Protocol that all have unique + Hostname values. 2. Multiple Listeners with the same Port that use + either the \"HTTPS\" or \"TLS\" Protocol that all have unique Hostname + values. 3. A mixture of \"TCP\" and \"UDP\" Protocol Listeners, + where no Listener with the same Protocol has the same Port value. + \n Some fields in the Listener struct have possible values that + affect whether the Listener is distinct. Hostname is particularly + relevant for HTTP or HTTPS protocols. \n When using the Hostname + value to select between same-Port, same-Protocol Listeners, the + Hostname value must be different on each Listener for the Listener to be distinct. \n When the Listeners are distinct based on Hostname, inbound request hostnames MUST match from the most specific to least specific Hostname values to choose the correct Listener and its @@ -179,25 +180,33 @@ spec: that are not distinct, then those Listeners are Conflicted, and the implementation MUST set the \"Conflicted\" condition in the Listener Status to \"True\". \n Implementations MAY choose to accept - a Gateway with Conflicted Listeners if they accept a partial Listener - set that contains no Conflicted Listeners. They MUST set a \"ListenersNotValid\" - condition the Gateway Status when the Gateway contains Conflicted + a Gateway with some Conflicted Listeners only if they only accept + the partial Listener set that contains no Conflicted Listeners. + To put this another way, implementations may accept a partial Listener + set only if they throw out *all* the conflicting Listeners. No picking + one of the conflicting listeners as the winner. This also means + that the Gateway must have at least one non-conflicting Listener + in this case, otherwise it violates the requirement that at least + one Listener must be present. \n The implementation MUST set a \"ListenersNotValid\" + condition on the Gateway Status when the Gateway contains Conflicted Listeners whether or not they accept the Gateway. That Condition - SHOULD clearly indicate in the Message which Listeners are conflicted. - \n A Gateway's Listeners are considered \"compatible\" if: \n 1. - They are distinct. 2. The implementation can serve them in compliance - with the Addresses requirement that all Listeners are available - on all assigned addresses. \n Compatible combinations in Extended - support are expected to vary across implementations. A combination - that is compatible for one implementation may not be compatible - for another. \n For example, an implementation that cannot serve - both TCP and UDP listeners on the same address, or cannot mix HTTPS - and generic TLS listens on the same port would not consider those - cases compatible, even though they are distinct. \n Note that requests - SHOULD match at most one Listener. For example, if Listeners are - defined for \"foo.example.com\" and \"*.example.com\", a request - to \"foo.example.com\" SHOULD only be routed using routes attached - to the \"foo.example.com\" Listener (and not the \"*.example.com\" + SHOULD clearly indicate in the Message which Listeners are conflicted, + and which are Accepted. Additionally, the Listener status for those + listeners SHOULD indicate which Listeners are conflicted and not + Accepted. \n A Gateway's Listeners are considered \"compatible\" + if: \n 1. They are distinct. 2. The implementation can serve them + in compliance with the Addresses requirement that all Listeners + are available on all assigned addresses. \n Compatible combinations + in Extended support are expected to vary across implementations. + A combination that is compatible for one implementation may not + be compatible for another. \n For example, an implementation that + cannot serve both TCP and UDP listeners on the same address, or + cannot mix HTTPS and generic TLS listens on the same port would + not consider those cases compatible, even though they are distinct. + \n Note that requests SHOULD match at most one Listener. For example, + if Listeners are defined for \"foo.example.com\" and \"*.example.com\", + a request to \"foo.example.com\" SHOULD only be routed using routes + attached to the \"foo.example.com\" Listener (and not the \"*.example.com\" Listener). This concept is known as \"Listener Isolation\". Implementations that do not support Listener Isolation MUST clearly document this. \n Implementations MAY merge separate Gateways onto a single set @@ -975,27 +984,28 @@ spec: _also_ apply in that case). \n Practically, this means that each listener in a set MUST have a unique combination of Port, Protocol, and, if supported by the protocol, Hostname. \n Some combinations - of port, protocol, and TLS settings are are considered Core support - and MUST be supported by implementations if they support the associated - Route type: \n 1. HTTPRoute, Port: 80, Protocol: HTTP 2. HTTPRoute, - Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided - 3. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough \n - \"Distinct\" Listeners have the following property: \n The implementation - can match inbound requests to a single distinct Listener. When multiple - Listeners share values for fields (for example, two Listeners with - the same Port value), the implementation can match requests to only - one of the Listeners using other Listener fields. \n For example, - the following Listener scenarios are distinct: \n 1. Multiple Listeners - with the same Port that all use the \"HTTP\" Protocol that all have - unique Hostname values. 2. Multiple Listeners with the same Port - that use either the \"HTTPS\" or \"TLS\" Protocol that all have - unique Hostname values. 3. A mixture of \"TCP\" and \"UDP\" Protocol - Listeners, where no Listener with the same Protocol has the same - Port value. \n Some fields in the Listener struct have possible - values that affect whether the Listener is distinct. Hostname is - particularly relevant for HTTP or HTTPS protocols. \n When using - the Hostname value to select between same-Port, same-Protocol Listeners, - the Hostname value must be different on each Listener for the Listener + of port, protocol, and TLS settings are considered Core support + and MUST be supported by implementations based on their targeted + conformance profile: \n HTTP Profile \n 1. HTTPRoute, Port: 80, + Protocol: HTTP 2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: + Terminate, TLS keypair provided \n TLS Profile \n 1. TLSRoute, Port: + 443, Protocol: TLS, TLS Mode: Passthrough \n \"Distinct\" Listeners + have the following property: \n The implementation can match inbound + requests to a single distinct Listener. When multiple Listeners + share values for fields (for example, two Listeners with the same + Port value), the implementation can match requests to only one of + the Listeners using other Listener fields. \n For example, the following + Listener scenarios are distinct: \n 1. Multiple Listeners with the + same Port that all use the \"HTTP\" Protocol that all have unique + Hostname values. 2. Multiple Listeners with the same Port that use + either the \"HTTPS\" or \"TLS\" Protocol that all have unique Hostname + values. 3. A mixture of \"TCP\" and \"UDP\" Protocol Listeners, + where no Listener with the same Protocol has the same Port value. + \n Some fields in the Listener struct have possible values that + affect whether the Listener is distinct. Hostname is particularly + relevant for HTTP or HTTPS protocols. \n When using the Hostname + value to select between same-Port, same-Protocol Listeners, the + Hostname value must be different on each Listener for the Listener to be distinct. \n When the Listeners are distinct based on Hostname, inbound request hostnames MUST match from the most specific to least specific Hostname values to choose the correct Listener and its @@ -1015,25 +1025,33 @@ spec: that are not distinct, then those Listeners are Conflicted, and the implementation MUST set the \"Conflicted\" condition in the Listener Status to \"True\". \n Implementations MAY choose to accept - a Gateway with Conflicted Listeners if they accept a partial Listener - set that contains no Conflicted Listeners. They MUST set a \"ListenersNotValid\" - condition the Gateway Status when the Gateway contains Conflicted + a Gateway with some Conflicted Listeners only if they only accept + the partial Listener set that contains no Conflicted Listeners. + To put this another way, implementations may accept a partial Listener + set only if they throw out *all* the conflicting Listeners. No picking + one of the conflicting listeners as the winner. This also means + that the Gateway must have at least one non-conflicting Listener + in this case, otherwise it violates the requirement that at least + one Listener must be present. \n The implementation MUST set a \"ListenersNotValid\" + condition on the Gateway Status when the Gateway contains Conflicted Listeners whether or not they accept the Gateway. That Condition - SHOULD clearly indicate in the Message which Listeners are conflicted. - \n A Gateway's Listeners are considered \"compatible\" if: \n 1. - They are distinct. 2. The implementation can serve them in compliance - with the Addresses requirement that all Listeners are available - on all assigned addresses. \n Compatible combinations in Extended - support are expected to vary across implementations. A combination - that is compatible for one implementation may not be compatible - for another. \n For example, an implementation that cannot serve - both TCP and UDP listeners on the same address, or cannot mix HTTPS - and generic TLS listens on the same port would not consider those - cases compatible, even though they are distinct. \n Note that requests - SHOULD match at most one Listener. For example, if Listeners are - defined for \"foo.example.com\" and \"*.example.com\", a request - to \"foo.example.com\" SHOULD only be routed using routes attached - to the \"foo.example.com\" Listener (and not the \"*.example.com\" + SHOULD clearly indicate in the Message which Listeners are conflicted, + and which are Accepted. Additionally, the Listener status for those + listeners SHOULD indicate which Listeners are conflicted and not + Accepted. \n A Gateway's Listeners are considered \"compatible\" + if: \n 1. They are distinct. 2. The implementation can serve them + in compliance with the Addresses requirement that all Listeners + are available on all assigned addresses. \n Compatible combinations + in Extended support are expected to vary across implementations. + A combination that is compatible for one implementation may not + be compatible for another. \n For example, an implementation that + cannot serve both TCP and UDP listeners on the same address, or + cannot mix HTTPS and generic TLS listens on the same port would + not consider those cases compatible, even though they are distinct. + \n Note that requests SHOULD match at most one Listener. For example, + if Listeners are defined for \"foo.example.com\" and \"*.example.com\", + a request to \"foo.example.com\" SHOULD only be routed using routes + attached to the \"foo.example.com\" Listener (and not the \"*.example.com\" Listener). This concept is known as \"Listener Isolation\". Implementations that do not support Listener Isolation MUST clearly document this. \n Implementations MAY merge separate Gateways onto a single set