Change:
5.3. <ins> Most security parameters, e.g., TLS ciphersuites, local identity and private key, etc., may be configured statically.  Others are dynamically configured during connection establishment.  Thus, we partition security parameters and callbacks based on their place in the lifetime of connection establishment.  Similar to transport parameters, both parameters and callbacks are inherited during cloning (see groups). 5.3.1. </ins> Common parameters such as TLS ciphersuites are known to <del> implementations.  Clients SHOULD use common safe defaults for these </del> <ins> implementations.  Clients should use common safe defaults for these </ins> values whenever possible.  However, as discussed in I-D.ietf-taps- transport-security, many transport security protocols require specific security parameters and constraints from the client at the time of configuration and actively during a handshake.  These <del> configuration parameters are created as follows </del> <ins> configuration parameters are created as follows: </ins> Security configuration parameters and sample usage follow: Local identity and private keys: Used to perform private key operations and prove one's identity to the Remote Endpoint. (Note, if private keys are not available, e.g., since they are <del> stored in HSMs, handshake callbacks MUST be used.  See below for </del> <ins> stored in HSMs, handshake callbacks must be used.  See below for </ins> details.) Supported algorithms: Used to restrict what parameters are used by underlying transport security protocols.  When not specified, <del> these algorithms SHOULD default to known and safe defaults for the </del> <ins> these algorithms should default to known and safe defaults for the </ins> system.  Parameters include: ciphersuites, supported groups, and signature algorithms. <del> Session cache: Used to tune cache capacity, lifetime, re-use, and eviction policies, e.g., LRU or FIFO. </del> <ins> Session cache management: Used to tune cache capacity, lifetime, re-use, and eviction policies, e.g., LRU or FIFO.  Constants and policies for these interfaces are implementation-specific. </ins> <del> Pre-shared keying material: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is associated with some identity that typically identifies its use or has some protocol-specific meaning to the Remote Endpoint. </del> <ins> Pre-Shared Key import: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is associated with some identity that typically identifies its use or has some protocol-specific meaning to the Remote Endpoint. 5.3.2. </ins> Security decisions, especially pertaining to trust, are not static. <del> Thus, once configured, parameters must also be supplied during live handshakes.  These are best handled as client-provided callbacks. Security handshake callbacks include: </del> <ins> Once configured, parameters may also be supplied during connection establishment.  These are best handled as client-provided callbacks. Security handshake callbacks that may be invoked during connection establishment include: </ins> Trust verification callback: Invoked when a Remote Endpoint's trust must be validated before the handshake protocol can proceed.

Discussion:
Make sure all the examples in the API and interface drafts use constants agnostic to argument type and syntax. From Dave Thaler: On 2 May 2018, at 03:07, Dave Thaler wrote:
will fix this when it lands
Addressed by .
Security properties should be synchronized with (the next rev of) URL
Addressed by .
lgtm