Change:
service name/port. Local Endpoint: The Local Endpoint represents the application's <del> name for itself that it wants to use for transport connections. For example, a local IP address and port. </del> <ins> name for itself that it uses for transport connections.  For example, a local IP address and port. </ins> Path Selection Properties: The Path Selection Properties consist of the options that an application may set to influence the <del> selection of paths between itself and the Remote Endpoint.  These options can come in the form of requirements, prohibitions, or preferences.  Examples of options which may influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like Maximum Transmission Unit (MTU) or discovered like Path MTU (PMTU), or predicted based on cached information like expected throughput or latency. </del> <ins> selection of paths between the Local Endpoint and the Remote Endpoint.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that may influence path selection include the interface type (such as a Wi- Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like Maximum Transmission Unit (MTU) or discovered like Path MTU (PMTU), or predicted based on cached information like expected throughput or latency. </ins> Protocol Selection Properties: The Protocol Selection Properties consist of the options that an application may set to influence the selection of transport protocol, or to configure the behavior <del> of generic transport protocol features.  These options come in the form of requirements, prohibitions, and preferences.  Examples </del> <ins> of generic transport protocol features.  These options can take the form of requirements, prohibitions, and preferences.  Examples </ins> include reliability, service class, multipath support, and fast open support.

Discussion:
Integrate Gorry's comments from This does not yet address Gorry's two other issues, which cover the background section, or potentially moving the transport implementation earlier in the document.
These issues mostly relate to the ARCH document wording: Section: Introduction It looks to me like we should have a reference after:/the BSD socket() interface./ Section: Background. > Section: Transport Services Architecture and Concepts The Application box seems one character wider than the TAPS boxes. i know apps are important to APIs, but suspect this is just a typo with extra '-' characters! /primarily offer knobs that are applicable to multiple transports/ Understand /knobs/, but suspect someone who does not speak English as a first language could be most puzzled, can we use a different word please? This may be something: /by which data transmission is ceased/ To me this doesn't read as common English and would be: /by which data transmission is stopped/ /by which data transmission ceases/ /Endpoint can vary in levels of specificity/ /Endpoint/ and /vary..specificity/ ... does it really vary, this seems difficult to pin down. Is this better as: /An Endpoint may be specified at various levels/? /that it wants to use for transport connections/ ... surely it does use it, or is more intended (if so, what)? Is it simpler as: /that it uses for transport connections/ /paths between itself and the Remote Endpoint/ I think strictly speaking, it is not between the App and the remote endpoint, but the local and remote endpoints, so could I suggest: /paths between the Local Endpoint and the Remote Endpoint/ /These options can come in the form of / could this be written: /These options can take the form of / -- appears multiple times in the ID. /Examples of options which may influence/ should be: /Examples of options that may influence/ /but that if this protocol is employed, a particular set of options should be used./ understood, is it even clearer (or not) as: /but that if this protocol is employed, a particular set of options should then be used./ In Section: Establishment Actions and Data Transfer Objects and Actions and Termination Actions:: I read this as definitions of terms, but there is no syntax that helps someone understand this.

Would it look foolish to include a colon or something after each term (as for the case currently defining message), so it is super clear that this is the defining para? In Section: Establishment Actions /Connection to a remote endpoint/ Could remote endpoint be capitalised here to be consistent with earlier? /for example, to a TCP simultaneous open./ do we need an info reference here. (Sadly, many people will not know what this is). In Section: Data Transfer Objects and Actions / Messages may or may not be usable if incomplete or corrupted. / Agree, but not entirely clear, so I think we should explain to the reader. Could we say: /If a received Message is incomplete or corrupted, it may or may not be usable by a specific application./ In Section: Transport System Implementation Concepts /the functionality of transport networking/ what is transport networking? - either define or rephrase, e.g. as: /the functionality required to provide a transport service across a network/ In Section: Connection Group: /Connection Group: A Connections Group/ mixed single and plural, suggest: /Connection Group: A Connection Group/ /Path: A Path represents an available set of properties of a network route on which packets may be sent or received./ I'm not so happy with this. I know people use terms in various ways but to me this is not a route. I'd prefer something like: /Path: A Path represents an available set of properties that a Local Endpoint may use to send or receive packets with a Remote Endpoint./ I think we need to define /candidate/ in some way, e.g. something like: a path or protocol identified in the gathering stage over which a connection may be attempted in the racing stage/. Also I'd much prefer to actually the two terms (as we currently do in the earlier figure): /Candidate Gathering/ and /Candidate Racing/ The present contents of, provides a set of definitions which are fine... /Transport System Implementation Concepts/ but I really wonder if I could suggest something slightly different. I wonder if we could call this /Transport System Concepts/ and move this way forward in the document to provide a nice early introduction of these terms (with forward refs to sections where these are discussed - if that appeals.

Things I'd like to see in this section: /Transport System Implementation Concepts/ Can we add a couple of sentences on gathering and racing, just to explain this using the terms used in the /lifetime of a connection/ figure. Can we create small subsections on /Cached State/ and /System Policy/ I think the subsection section titles below should be changed: /Gathering//Candidate Gathering/ and /Candidate Racing/Candidate Racing/ /### Message Framing, Parsing, and Serialization {#framing}/ This subsection appears out-of sequence. (Actually this could really help the reader if made a little easier to read and placed ahead of discussing the details). >
Closing this, we can discuss details in PR
lgtm