Change:
Two items here: Normative MUST? I guess this is just a guidance document so doesn't need anything normative. There's some later "should" as well which I would generally ask the same question for. but... here we have some NORMATIVE language. That SHOULD should probably be non-capitalised to align with earlier usage. (and so on later in the document, e.g. in the SCTP description)
The first one can just be "uses the default values", without normative text. Second one can be lowercase as well. SCTP has normative SHOULDs and MUSTs that can be removed.

Discussion:
The implementation stores these properties as a part of the Preconnection object for use during connection establishment.  For Selection Properties that are not provided by the application, the <del> implementation must use the default values specified in the Transport </del> <ins> implementation uses the default values specified in the Transport </ins> Services API (I-D.ietf-taps-interface). 3.1.

Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting data back to the Message Framer, which will in turn send it to the <del> next protocol.  To improve performance, implementations SHOULD ensure </del> <ins> next protocol.  To improve performance, implementations should ensure </ins> that there is a way to pass the original data through without copying.

that a new incoming stream should be represented as a new Connection Object by the Transport Services system.  A new SCTP stream is created by sending an SCTP message with a new stream id.  Thus, to <del> implement stream mapping, the Transport Services API MUST provide a </del> <ins> implement stream mapping, the Transport Services API must provide a </ins> newly created Connection Object to the application upon the reception of such a message.  The necessary semantics to implement a Transport Services system Close and Abort primitives are provided by the stream reconfiguration (reset) procedure described in RFC6525.  This also allows to re-use a stream id after resetting ("closing") the stream. To implement this functionality, SCTP stream reconfiguration RFC6525 <del> MUST be supported by both the client and the server side. </del> <ins> must be supported by both the client and the server side. </ins> <del> To avoid head-of-line blocking, stream mapping SHOULD only be </del> <ins> To avoid head-of-line blocking, stream mapping should only be </ins> implemented when both sides support message interleaving RFC8260. This allows a sender to schedule transmissions between multiple streams without risking that transmission of a large message on one

To avoid conflicts between stream ids, the following procedure is recommended: the first Connection, for which the SCTP association has <del> been created, MUST always use stream id zero.  All additional </del> <ins> been created, must always use stream id zero.  All additional </ins> Connections are assigned to unused stream ids in growing order.  To avoid a conflict when both endpoints map new Connections <del> simultaneously, the peer which initiated association MUST use even stream ids whereas the remote side MUST map its Connections to odd </del> <ins> simultaneously, the peer which initiated association must use even stream ids whereas the remote side must map its Connections to odd </ins> stream ids.  Both sides maintain a status map of the assigned stream <del> ids.  Generally, new streams SHOULD consume the lowest available </del> <ins> ids.  Generally, new streams should consume the lowest available </ins> (even or odd, depending on the side) stream id; this rule is relevant when lower ids become available because Connection objects associated with the streams are closed.