Change:
9.1.1. <del> Boolean This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The recommended default is to have this option. 9.1.2. </del> Integer This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". <del> 9.1.3. Boolean This property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  When set to true, received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The recommended default is not to have this option. 9.1.4. </del> <ins> 9.1.2. </ins> Integer

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.