Change:
of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. <del> 9.1.6. </del> <ins> 9.1.4. </ins> This property specifies how long to wait before deciding that a Connection has failed after establishment. <del> 9.1.7. </del> <ins> 9.1.5. </ins> Enum

Discussion:
This and addresses a comment about soft errors by NAME in : "Notification of Excessive Retransmission" is made a Selection Property There's now an "Excessive Retransmission" Event (just like the one for Soft Errors) The preference to receive Soft Errors is also made a Selection Property
Oops sorry, will fix
NAME - the latter was exactly my thinking. if someone doesn’t want these notifications they can just ignore them.
I think we should not standardise this. I also don't think that IETF transports typically provide this control, nor do I think this is really useful to have. So I'd argue the API should be silent about these three things!
I agree with Gorry that you can probably remove them. If anything I would see it as a Connection properties, not as Selection properties. How likely is it that you will have two transport stacks to select from where one supports soft errors the other not and this is what you will want to use to make a decision? Does not seem like a strong use case.
To Gorry's point, how widely do we expect these to be supported for various protocols? And is the meaning of excessive retransmits consistent across protocols that do retransmission (TCP, SCTP, QUIC)?
I certainly agree that it seems unlikely that someone will want to insist on a transport that offers "Notification of Excessive Retransmission". Removing this selection property is fine by me. Regarding soft errors, I could agree but I'm less sure - so just to double check, are we really all sure we don't want to offer this kind of control? What if applications really want to be able to receive ICMP messages, e.g. to insist on doing their own PMTUD? NAME mentions that, if anything, they should be Connection Properties: I agree with that; they were both Connection Properties before, but with unfitting wording (fixing this was a part of this split). I think they should both be described as events, like we already have it for soft errors only: https://taps-URL We shouldn't remove them altogether: if we did, this would AFAIK be our only divergence from minset.

To answer NAME question, I dont know what most implementations do about these two things - but here's a spec backtrace that talks about TCP and UDP (for other protocols, "do nothing" is a safe choice here I guess): About "Notification of Excessive Retransmission", minset's Appendix A.1 says: o Notification of Excessive Retransmissions (early warning below abortion threshold) Protocols: TCP Optimizing because it is an early warning to the application, informing it of an impending functional event. Implementation: via ERROR.TCP. Implementation over UDP: do nothing (there is no abortion threshold). RFC 8303, section 4.1 ("pass 2"), says about ERROR.TCP: "The reported conditions include at least: ICMP error message arrived and excessive retransmissions." For the soft errors bit, minset also points at ERROR.UDP(-Lite), which, in RFC 8303, is described to just return soft errors, nothing else. For both protocols, the text points back at "errorreport" from pass 1, which in TCP's case points back at section 4.2.4.1 in RFC 1122: URL The text also refers to RFC 5461 which may provide more information regarding NAME question. For soft errors from UDP, we need to look at "errorreport" in RFC 8304, which quotes section 4.1.4 or RFC1122 to say: "UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer." and goes on to explain that this is necessary to implement ICMP-based PMTUD.
As discussed in
Looks good to me. I think there was the idea to have an additional Connection Property, which allows to turn the soft errors on or off on an existing Connection. Do we want to standardize this additional Connection Property as well, or is this too much and we leave it up to the implementation whether such a thing exists? I tend towards the latter, as I consider this just a convenience function.