Change:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good

Discussion:
optimize its behavior based on the application requirements and network conditions, without requiring changes to the applications. This flexibility enables faster deployment of new features and <del> protocols.  It can support applications by offering racing and </del> <ins> protocols, and can support applications by offering racing and </ins> fallback mechanisms, which otherwise need to be separately implemented in each application. <del> It derives specific path and protocol selection properties and </del> <ins> This API derives specific path and protocol selection properties and </ins> supported transport features from the analysis provided in RFC8095, RFC8923, and RFC8922.  The design encourages implementations underneath the interface to dynamically choose a transport protocol

The following notations, which can be combined, are used in this document: <del> An Action creates an Object: </del> <ins> An Action that creates an Object: </ins> <del> An Action creates an array of Objects: </del> <ins> An Action that creates an array of Objects: </ins> <del> An Action is performed on an Object: </del> <ins> An Action that is performed on an Object: </ins> An Object sends an Event:

ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the <del> Preconnection (i.e.  peer to peer establishment; rendezvous). </del> <ins> Preconnection (i.e., peer to peer establishment; rendezvous). </ins> Once a Connection is established, data can be sent and received on it in the form of Messages.  The interface supports the preservation of

3.1. The following usage examples illustrate how an application might use <del> a Transport Services Interface to: </del> <ins> the Transport Services Interface to: </ins> Act as a server, by listening for incoming connections, receiving requests, and sending responses, see server-example.

but the list of Remote Endpoints MAY be empty if the Preconnection is used to Listen() for incoming Connections.  At least one Local Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer <del> Rendezvous is to occur based on the Preconnection. </del> <ins> Rendezvous() is to occur based on the Preconnection. </ins> If more than one Local Endpoint is specified on a Preconnection, then all the Local Endpoints on the Preconnection MUST represent the same

An Endpoint Object can be configured with the following identifiers: <del> Hostname (string) </del> <ins> Hostname (string): </ins> <del> Port (a 16-bit integer) or a Service (string) that maps to a port </del> <ins> Port (a 16-bit integer) or a Service (string) that maps to a port: </ins> <del> IP address (IPv4 or IPv6 address) </del> <ins> IP address (IPv4 or IPv6 address): </ins> <del> Interface (string name) </del> <ins> Interface name (string): </ins> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two

4.3.1. <del> Common parameters such as TLS ciphersuites are known to </del> <ins> Common security parameters such as TLS ciphersuites are known to </ins> implementations.  Clients should use common safe defaults for these values whenever possible.  However, as discussed in RFC8922, many transport security protocols require specific security parameters and