Original text:
9. <del> At any point, the application can query Connection Properties.  It can also set per-connection Protocol Properties. </del>  Depending on the status of the connection, the queried Connection Properties will include different information: For Connections that are Establishing: Transport Properties that the application specified on the Preconnection, see connection- <del> props.  Selection Properties of a Connection can only be queried, not set. </del>  For Connections that are Established, Closing, or Closed (TODO: double-check if closed belongs here): Transport Properties of the Property that an application specified as Preferred may not actually be present in the chosen protocol stack because none of the currently available transport protocols had this <del> feature.  Selection Properties of a Connection can only be queried. </del>  Protocol Properties of the protocol stack in use (see protocol- <del> props below).  These can be queried and set.  Certain specific Procotol Properties may be read-only, on a protocol- and property-specific basis. </del>  For Connections that are Established, properties of the path(s) in use.  These properties can be derived from the local provisioning domain RFC7556, measurements by the Protocol Stack, or other <del> sources.  They can only be queried. </del>  10. aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. <del> A SoftError can inform the application about the receipt of an ICMP error message that does not force termination of the connection, if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </del> 11. As this interface is designed to be independent of an

Reviewer comments:
Rather than saying "this can only be queried" everywhere, I split this into setting and querying now, and I also moved SoftErrors in there. It's not precisely "querying" for a Property, but it's the closest match - better than "Connection Termination", I think (this is where SoftErrors were before).
NAME what about "Connection Maintenance: Setting Properties and Obtaining Information" ?
Maintenance sounds a bit strange to me, "Managing Connections: Setting Properties and Obtaining Information" ?
I like it (and I agree about "maintenance" being slightly strange)
Managing sounds good to me too.
Ack, done
lgtm, thanks!

Revised text:
9.  <ins> The application can set per-connection Protocol Properties (see protocol-props).  Certain Procotol Properties may be read-only, on a protocol- and property-specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~ </ins> Depending on the status of the connection, the queried Connection Properties will include different information: For Connections that are Establishing: Transport Properties that the application specified on the Preconnection, see connection-  <ins> props. </ins> For Connections that are Established, Closing, or Closed (TODO: double-check if closed belongs here): Transport Properties of the Property that an application specified as Preferred may not actually be present in the chosen protocol stack because none of the currently available transport protocols had this  <ins> feature. </ins> Protocol Properties of the protocol stack in use (see protocol-  <ins> props). </ins> For Connections that are Established, properties of the path(s) in use.  These properties can be derived from the local provisioning domain RFC7556, measurements by the Protocol Stack, or other  <ins> sources. Slightly different from "querying", a SoftError Event can also occur, informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </ins> 10. aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled.  11. As this interface is designed to be independent of an