Original text:
should be immediately closed by sending a RST to the peer (ABORT.TCP).  10.2. Connectedness: Connected Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close". <del> 10.4. </del>  Connectedness: Connectionless Coverage on Sending", "Required Minimum Corruption Protection Coverage for Receiving", and "Full Checksum Coverage on Receiving". <del> 10.5. </del>  Connectedness: Connectionless Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) is identical to calling "Close". <del> 10.6. </del>  Connectedness: Connected same SCTP assocation, and shutdown proceeds as described under "Close".  11. RFC-EDITOR: Please remove this section before publication.

Reviewer comments:
So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!

Revised text:
should be immediately closed by sending a RST to the peer (ABORT.TCP). <ins> Calling "CloseGroup" on a TCP Connection (CLOSE.TCP) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a TCP Connection (ABORT.TCP) is identical to calling "Abort" on this Connection and on all Connections in the same ConnectionGroup. </ins> 10.2. Connectedness: Connected Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close".  <ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup.  ## UDP-Lite </ins> Connectedness: Connectionless Coverage on Sending", "Required Minimum Corruption Protection Coverage for Receiving", and "Full Checksum Coverage on Receiving".  <ins> 10.4. </ins> Connectedness: Connectionless Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) is identical to calling "Close".  <ins> Calling "CloseGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. 10.5. </ins> Connectedness: Connected same SCTP assocation, and shutdown proceeds as described under "Close". <ins> CloseGroup: Calling "CloseGroup" calls CLOSE.SCTP, closing all Connections in the SCTP association. AbortGroup: Calling "AbortGroup" calls ABORT.SCTP, immediately closing all Connections in the SCTP association. </ins> 11. RFC-EDITOR: Please remove this section before publication.