Change:
This PR addresses a few outstanding formatting cleanup issues: Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns
Merging on my own since these are just formatting changes.
This : ... is probably not a single paragraph. Similar problems and . It might be worth a more thorough proof-read of the document for others similar formatting problems.

Discussion:
The first byte in the SFrame header has a fixed format and contains the header metadata: <del> Reserved (R): 1 bit This field MUST be set to zero on sending, and MUST be ignored by receivers.  Counter Length (LEN): 3 bits This field indicates the length of the CTR field in bytes, minus one (the range of possible values is thus 1-8).  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. Key or Key Length: 3 bits This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0 then the KID is in the range of 0-7 and the counter </del> <ins> This field MUST be set to zero on sending, and MUST be ignored by receivers. This field indicates the length of the CTR field in bytes, minus one (the range of possible values is thus 1-8). Indicates if the key field contains the key id or the key length. This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0, then the KID is in the range of 0-7 and the counter </ins> (CTR) is found in the next LEN bytes: <del> if X flag is 1 then KLEN is the length of the key (KID).  The KID is </del> <ins> If X flag is 1 then KLEN is the length of the key (KID).  The KID is </ins> encoded in the KLEN bytes following the metadata byte, and the counter (CTR) is encoded in the next LEN bytes:

Each SFrame session uses a single ciphersuite that specifies the following primitives: <del> o A hash function used for key derivation </del> <ins> A hash function used for key derivation </ins> <del> o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag </del> <ins> An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag </ins> This document defines the following ciphersuites:

6.1. <del> Selective Forwarding Units (SFUs) as described in https://tools.ietf.org/html/rfc7667#section-3.7 receives the RTP streams from each participant and selects which ones should be forwarded to each of the other participants.  There are several approaches about how to do this stream selection but in general, in order to do so, the SFU needs to access metadata associated to each frame and modify the RTP information of the incoming packets when they are transmitted to the received participants. </del> <ins> Selective Forwarding Units (SFUs) as described in Section 3.7 of RFC7667 receives the RTP streams from each participant and selects which ones should be forwarded to each of the other participants. There are several approaches about how to do this stream selection but in general, in order to do so, the SFU needs to access metadata associated to each frame and modify the RTP information of the incoming packets when they are transmitted to the received participants. </ins> This section describes how this normal SFU modes of operation interacts with the E2EE provided by SFrame

O/A required to establish a new RTP stream, the SFU may decide to reuse previously existing RTP sessions or even pre-allocate a predefined number of RTP streams and choose in each moment in time <del> which participant media will be sending through it.  This means that in the same RTP stream (defined by either SSRC or MID) may carry media from different streams of different participants.  As different keys are used by each participant for encoding their media, the receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another participant's media. </del> <ins> which participant media will be sending through it. This means that in the same RTP stream (defined by either SSRC or MID) may carry media from different streams of different participants.  As different keys are used by each participant for encoding their media, the receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another participant's media. </ins> Note that in order to prevent impersonation by a malicious participant (not the SFU), a mechanism based on digital signature

The encryption overhead will vary between audio and video streams, because in audio each packet is considered a separate frame, so it will always have extra MAC and IV, however a video frame usually <del> consists of multiple RTP packets.  The number of bytes overhead per frame is calculated as the following 1 + FrameCounter length + 4 The constant 1 is the SFrame header byte and 4 bytes for the HBH </del> <ins> consists of multiple RTP packets. The number of bytes overhead per frame is calculated as the following The constant 1 is the SFrame header byte and 4 bytes for the HBH </ins> authentication tag for both audio and video packets. 7.1. <del> Using three different audio frame durations 20ms (50 packets/s) 40ms (25 packets/s) 100ms (10 packets/s) Up to 3 bytes frame counter (3.8 days of data for 20ms frame duration) and 4 bytes fixed MAC length. </del> <ins> Using three different audio frame durations 20ms (50 packets/s) 40ms (25 packets/s) 100ms (10 packets/s) Up to 3 bytes frame counter (3.8 days of data for 20ms frame duration) and 4 bytes fixed MAC length. </ins> 7.2. The per-stream overhead bits per second as calculated for the <del> following video encodings: 30fps@1000Kbps (4 packets per frame) 30fps@512Kbps (2 packets per frame) 15fps@200Kbps (2 packets per frame) 7.5fps@30Kbps (1 packet per frame) Overhead bps = (Counter length + 1 + 4 ) * 8 * fps </del> <ins> following video encodings: 30fps @ 1000Kbps (4 packets per frame) 30fps @ 512Kbps (2 packets per frame) 15fps @ 200Kbps (2 packets per frame) 7.5fps @ 30Kbps (1 packet per frame) Overhead "bps = (Counter length + 1 + 4 ) * 8 * fps" </ins> 7.3. RFC8723 has significant overhead over SFrame because the overhead is per packet, not per frame, and OHB (Original Header Block) which <del> duplicates any RTP header/extension field modified by the SFU.  I- D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/ </del> <ins> duplicates any RTP header/extension field modified by the SFU. I-D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/ </ins> SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't use the OHB anymore, however it still does per packet encryption <del> using SRTP.  Below the the overheard in I-D.murillo-perc-lite implemented by Cosmos Software which uses extra 11 bytes per packet to preserve the PT, SEQ_NUM, TIME_STAMP and SSRC fields in addition to the extra MAC tag per packet. </del> <ins> using SRTP. Below the the overheard in I-D.murillo-perc-lite implemented by Cosmos Software which uses extra 11 bytes per packet to preserve the "PT", "SEQ_NUM", "TIME_STAMP" and "SSRC" fields in addition to the extra MAC tag per packet. </ins> <del> OverheadPerPacket = 11 + MAC length Overhead bps = PacketPerSecond * OverHeadPerPacket * 8 </del> <ins> "OverheadPerPacket = 11 + MAC length Overhead bps = PacketPerSecond * OverHeadPerPacket * 8 " </ins> Similar to SFrame, we will assume the HBH authentication tag length will always be 4 bytes for audio and video even though it is not the

these parameters (hex encoded) An implementation should reproduce the output values given the input <del> values: * An implementation should be able to encrypt with the input values and the plaintext to produce the ciphertext.  * An implementation must be able to decrypt with the input values and the ciphertext to generate the plaintext. </del> <ins> values: An implementation should be able to encrypt with the input values and the plaintext to produce the ciphertext. An implementation must be able to decrypt with the input values and the ciphertext to generate the plaintext. </ins> Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed