Original text:
1.1. <del> This API is described in terms of Objects with which an application can interact; Actions the application can perform on these Objects; Events, which an Object can send to an application asynchronously; and Parameters associated with these Actions and Events. </del>  The following notations, which can be combined, are used in this document: interface itself; they are equivalent to Actions on a per-application global context.  We also make use of the following basic types: Boolean: Instances take the value "true" or "false". can have multiple aliases set. In order to scope an alias to a specific transport protocol, an <del> Endpoint can specify a protocol identifier.  These identifiers MUST only be set for aliases. </del>  The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC. to those that would be sent by an invocation of Initiate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established <del> will not result in a SendError separate from the InitiateError </del>  signaling the failure of Connection establishment. 7.2.6. Closed<> occurs when a Connection transitions to Closed state without error. <del> InitiateError<> occurs when a Connection created with Initiate() transitions from Establishing state to Closed state due to an error. </del>  ConnectionError<> occurs when a Connection transitions to Closed state due to an error in all other circumstances. Connection. No events will occur on a Connection after it is Closed; i.e., <del> after a Closed<> event, an InitiateError<> or ConnectionError<> will not occur on that connection.  To ensure this ordering, Closed<> will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the interface and waiting to be dealt with by the application). </del>  10.

Reviewer comments:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.

Revised text:
1.1.  <ins> This API is described in terms of Objects with which an application can interact; Actions the application can perform on these Objects; Events, which an Object can send to an application to be processed aynchronously; and Parameters associated with these Actions and Events. </ins> The following notations, which can be combined, are used in this document: interface itself; they are equivalent to Actions on a per-application global context. <ins> Events are sent to the application or application-supplied code (e.g. framers, see framing) for processing; the details of event processing are platform- and implementation-specific. </ins> We also make use of the following basic types: Boolean: Instances take the value "true" or "false". can have multiple aliases set. In order to scope an alias to a specific transport protocol, an  <ins> Endpoint can specify a protocol identifier. </ins> The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC. to those that would be sent by an invocation of Initiate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established  <ins> will not result in a SendError separate from the EstablishmentError </ins> signaling the failure of Connection establishment. 7.2.6. Closed<> occurs when a Connection transitions to Closed state without error.  <ins> EstablishmentError<> occurs when a Connection created with Initiate() transitions from Establishing state to Closed state due to an error. </ins> ConnectionError<> occurs when a Connection transitions to Closed state due to an error in all other circumstances. Connection. No events will occur on a Connection after it is Closed; i.e.,  <ins> after a Closed<> event, an EstablishmentError<> or ConnectionError<> will not occur on that connection.  To ensure this ordering, Closed<> will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the interface and waiting to be dealt with by the application). </ins> 10.