Changes according to https://mailarchive.ietf.org/arch/msg/taps/BrKFf…

…pcnwbTneXfhGAqvdnnaa4Q/
ietf-tapswg · Mar 29, 2023 · e36a3a3 · e36a3a3
1 parent a905f48
commit e36a3a3
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/draft-ietf-taps-arch.md b/draft-ietf-taps-arch.md
@@ -543,7 +543,7 @@ This section defines the key concepts of the Transport Services architecture.
 
 * System Policy: The input from an operating system or other global preferences that can constrain or influence how an implementation will gather candidate paths and Protocol Stacks ({{gathering}}) and race the candidates during establishment ({{racing}}). Specific aspects of the System Policy either apply to all Connections or only certain ones, depending on the runtime context and properties of the Connection.
 
-* Cached State: The state and history that the implementation keeps for each set of associated Endpoints that have been used previously. This can include DNS results, TLS session state, previous success and quality of transport protocols over certain paths, as well as other information.  This caching does not imply that the same decisions are necessarily made for subsequent connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc. An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request any required or desired properties via the Transport Services API.
+* Cached State: The state and history that the implementation keeps for each set of associated Endpoints that have been used previously. This can include DNS results, TLS session state, previous success and quality of transport protocols over certain paths, as well as other information.  This caching does not imply that the same decisions are necessarily made for subsequent connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc. An application SHOULD NOT rely on specific caching behaviour, instead it ought to explicitly request any required or desired properties via the Transport Services API.
 
 ### Candidate Gathering {#gathering}
 

diff --git a/draft-ietf-taps-interface.md b/draft-ietf-taps-interface.md
@@ -718,7 +718,7 @@ LocalSpecifier.WithInterface("en0")
 Note that an IPv6 address specified with a scope (e.g. `2001:db8:4920:e29d:a420:7461:7073:0a%en0`)
 is equivalent to `WithIPv6Address` with an unscoped address and `WithInterface ` together.
 
-An Endpoint MUST NOT be configured with multiple identifiers of the same type.
+The design of the API MUST NOT permit an Endpoint to be configured with multiple identifiers of the same type.
 For example, an endpoint cannot have two IP addresses specified. Two separate IP addresses
 are represented as two Endpoint Objects. If a Preconnection specifies a Remote
 Endpoint with a specific IP address set, it will only establish Connections to