Original text:
closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. <del> Abort terminates a Connection without delivering any remaining data. This action does not affect any other Connection that is entangled with this one in a Connection Group. </del>  <del> AbortGroup terminates a Connection and also terminates any other </del>  Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a <del> single session for a multistreaming protocol; aborting the entire group would close the underlying session.  See also groups. </del>  A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been

Reviewer comments:
Inspired by the discussion in , I don't think we adequately addressed . Abstracting away from current designs, in a connection group there are four possible termination actions: Clean close a connection Abort a connection Clean close a connection group Abort a connection group TAPS has all but the third. QUIC has three of these; SCTP has two (three with RFC 6525); HTTP/2, IIUC, in principle has all four, though I believe RFC 7540 doesn't envision HTTP/2 ever initiating TCP RST. There is an added complication that in some protocols these are half-closes or half-aborts. I think we're trying to be too cute by not offering all four of these. Let's just have all of them (which means adding CloseGroup) and then figure out how the protocol mappings respond to actions they don't actually support. For example Non-streaming protocols simply apply the close or abort to each of their connections. When QUIC gets CloseGroup, it sends clean close on all connections and then sends group abort. (Note that apps with mandatory streams [like HTTP3] can't use this functionality) When SCTP with 7525 gets ConnectionAbort, it does ConnectionClose instead When SCTP without 7525 gets ConnectionClose or ConnectionAbort, it's a NOP. When HTTP/2 gets AbortGroup, it sends GOAWAY followed by a CloseGroup.
I'm copy+pasting my answer from the PR here. I'm not against "let's just have all of them and then figure out how...", but I'm also not sure if we need to get so complex? Perhaps.... I'll just leave this text here for consideration: [paste from ] About stream abort: not quite, I think. Using a "stream abort" would mean that the TCP-like half-closed behavior wouldn't work - you couldn't send a stream reset and then expect to receive something on a stream. However, that isn't possible anyway, because SCTP streams are only unidirectional. And, there's only a guarantee of a notification by a returning "stream reset" because we define it in this PR. I agree that this is bigger and should be separate from this PR... but what's your plan? Do we really have a big problem here? In the end, it's a matter of having the right semantics at the API level. This began with just picking the strictest possible semantics: no half-closed connections, calling "close" means that what the app already gave to the transport system for transmission before the call will still be sent, but the app cannot expect to send or receive anything after this call. This way, SCTP (which doesn't allow half-closed associations) is covered, and the behavior is "correct" for TCP as well. These semantics also work for SCTP streams with stream reset as above. So... altogether, I thought we'll be safe if we just go strict. Now, quite recently, the wording was changed a bit, because of the need to support TCP half-closed connections (which is implemented via the "Final" Message Property). I felt a bit uneasy about this change, but in the end I couldn't see how things would go wrong with the wording that we now have in the API draft. My high-level view is that we still have this rather strict thing, and then there is the option to use "Final", with no guarantee of it working (because we don't know if we get a protocol that supports half-closed connections). But there may be a devil in the details on how we worded it... definitely worth another careful look.
I agree that our treatment of half and full closes is alright, although it doesn't give us away to do a QUIC STOP_SENDING frame, for example. I think the close and abort semantics are quite clear to the application developer, but it's not sufficient to have them at the Connection level because it can lead to many messages where one would suffice. I don't like that we've merged the SCTP SHUTDOWN and ABORT chunks, for instance.
Re: the need for more primitives to do, e.g., STOP_SENDING, I agree. Re: close and abort not being sufficient: I agree. Re: merging SCTP SHUTDOWN and ABORT chunks: that sounds like a mistake that we shouldn't have made. Which text in which draft gives you this impression? I checked the implementation draft, it talks about CLOSE.SCTP (for Close) and ABORT.SCTP (for Abort), and all of this is preceded by "Below, terms in capitals with a dot (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of [RFC8303]." In RFC 8303, these terms refer back to the Shutdown and Abort primitives of RFC 4960 (the current spec at the time RFC 8303 was written), where it is explained that these work using the SHUTDOWN and ABORT chunks... so where is the mistake?

Which text in which draft gives you this impression? IIUC, for multistreaming protocols Connection.Close() and Connection.Abort() apply to streams while Connection.AbortGroup() applies to the protocol connection/association. We lack a Connection.CloseGroup() and therefore there is no way to trigger a SHUTDOWN chunk. In practice, since stream closing capabilities are slim in SCTP, we can repurpose Close() and Abort(), but this seems conceptually messier.
discussed at 2021-02-26 interim: we are indeed being a little too cute by pretending an application isn't going to interact with groups. Decision is to add CloseGroup().
Looks good, thanks for doing this!

Revised text:
closed the Connection.  There is no guarantee that a remote Close will indeed be signaled.  <ins> Abort terminates a Connection without delivering any remaining Messages.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </ins>  <ins> CloseGroup gracefully terminates a Connection and any other </ins> Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a  <ins> single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections that are entangled with this one in a Connection Group without delivering any remaining Messages. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been