Original text:
convenience functions to simplify use of Selection Properties: see preference-conv for examples.  In addition, implementations MAY provide a mechanism to create TransportProperties objects that are <del> preconfigured for common use cases as outlined in property-profiles. </del>  Transport Properties for an established connection can be queried via the Connection object, as outlined in introspection. Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this <del> value for datagram transports is provided in RFC8085.  A value </del>  greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets. characteristics and habits of the user of an application. Of course any communication over a network reveals usage <del> characteristics, as all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </del>  information is visible, potentially in clear text, and which other entities can access it.  In most cases, information provided for protocol and path selection should not directly translate to

Reviewer comments:
The guidance applies to any connectionless transport.
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
LGTM

Revised text:
convenience functions to simplify use of Selection Properties: see preference-conv for examples.  In addition, implementations MAY provide a mechanism to create TransportProperties objects that are  <ins> preconfigured for common use cases, as outlined in property-profiles. </ins> Transport Properties for an established connection can be queried via the Connection object, as outlined in introspection. Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this  <ins> value for connection-less transports is provided in RFC8085.  A value </ins> greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets. characteristics and habits of the user of an application. Of course any communication over a network reveals usage  <ins> characteristics, because all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </ins> information is visible, potentially in clear text, and which other entities can access it.  In most cases, information provided for protocol and path selection should not directly translate to