Original text:
transfers.  The absence of options in the CSM indicates that base values are assumed.  Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). this server. The Alternative-Address elective option requests the peer to instead <del> open a connection of the same kind as the present connection to the </del>  alternative transport address given.  Its value is in the form "authority" as defined in Section 3.2 of RFC3986.

Reviewer comments:
Also clarifies that "same kind" in Alternate-Address refers to scheme.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?
NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.

Revised text:
transfers.  The absence of options in the CSM indicates that base values are assumed. <ins> To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (See max-message-size) that is smaller than the base value (1152). </ins> Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). this server. The Alternative-Address elective option requests the peer to instead  <ins> open a connection of the same scheme as the present connection to the </ins> alternative transport address given.  Its value is in the form "authority" as defined in Section 3.2 of RFC3986.