Original text:
an asynchronous operation, in which each call to Receive enqueues a request to receive new data from the connection.  Once data has been received, or an error is encountered, an event will be delivered to <del> complete the Receive request (see receive-events). As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's Transport Properties. </del>  8.1. or to assign the traffic to a lower-effort service.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling SHOULD assign the DSCP Less <del> than Best Effort LE-PHB PHB. </del>  The application is interactive, and prefers loss to latency. Response time should be optimized at the expense of bandwidth supported by the underlying transport; and so on.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD <del> assign the DSCP Expedited Forwarding RFC3246 PHB. </del>  The application prefers loss to latency but is not interactive. Response time should be optimized at the expense of bandwidth

Reviewer comments:
: added a statement about data arriving before Receive is issued; : removed the confusing sentence; : carried out replacements suggested by NAME
This issue comes from other discussion at the interim of what it means to map to DSCP classes, and proposes to fix two topics. Replace reference OLD: DSCP Less than Best Effort [LE-PHB] PHB NEW: DSCP Less than Best Effort [RFC8622] PHB — Low Latency/Interactive: The current advice is wrong. An endpoint never should be assigning EF without understanding the implication of CAC and policing. OLD: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; NEW: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) [RFC2597] PHB. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding [RFC3246] or [RFC5865] PHBs. —
The new text resolve this issue.
I'm not sure I understand this sentence (in sec 8. - Receiving Data): "As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's transport parameters." Especially, what's meant by "type of Message"?

Revised text:
an asynchronous operation, in which each call to Receive enqueues a request to receive new data from the connection.  Once data has been received, or an error is encountered, an event will be delivered to  <ins> complete any pending Receive requests (see receive-events).  If Messages arrive at the transport system before Receive requests are issued, ensuing Receive requests will first operate on these Messages before awaiting any further Messages. </ins> 8.1. or to assign the traffic to a lower-effort service.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling SHOULD assign the DSCP Less  <ins> than Best Effort RFC8622 PHB. </ins> The application is interactive, and prefers loss to latency. Response time should be optimized at the expense of bandwidth supported by the underlying transport; and so on.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD  <ins> assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) RFC2597 PHB.  Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding RFC3246 or RFC5865 PHBs. </ins> The application prefers loss to latency but is not interactive. Response time should be optimized at the expense of bandwidth