Original text:
key that needs to be used for decrypting. Both the frame counter and the key id are encoded in a variable <del> length format to decrease the overhead, so the first byte in the Sframe header is fixed and contains the header metadata with the following format: </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 <del> field indicates the length of the CTR fields in bytes.  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. </del>  If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes: <del> Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </del>  if X flag is 1 then KLEN is the length of the key (KID), that is found after the SFrame header metadata byte.  After the key id (KID), the frame counter (CTR) will be found in the next LEN bytes: <del> Key length (KLEN): 3 bits The key length in bytes.  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </del>  4.3. these parameters (hex encoded) An implementation should reproduce the output values given the input <del> values.  Encryption with the input values and the plaintext should produce the ciphertext.  Decryption with the input values and the ciphertext should produce the plaintext. </del>  Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed

Reviewer comments:
PR fixes URL PR also updates AES-CTR test vectors accordingly. PR clarifies that decryption ought to work but comparing encrypted data may sometimes fail.
The spec says: Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes. This probably means 000 is 1 byte, 001 is 2 bytes, and so on... It would be good to clarify this.

Revised text:
key that needs to be used for decrypting. Both the frame counter and the key id are encoded in a variable  <ins> length format to decrease the overhead.  The length is up to 8 bytes and is represented in 3 bits in the SFrame header: 000 represents a length of 1, 001 a length of 2... The first byte in the SFrame header is fixed and contains the header metadata with the following format: </ins> 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  <ins> field indicates the length of the CTR fields in bytes (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. </ins> If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes:  <ins> Frame counter byte length (LEN): 3bits The frame counter length in bytes (1-8).  Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> if X flag is 1 then KLEN is the length of the key (KID), that is found after the SFrame header metadata byte.  After the key id (KID), the frame counter (CTR) will be found in the next LEN bytes:  <ins> Frame counter byte length (LEN): 3bits The frame counter length in bytes (1-8).  Key length (KLEN): 3 bits The key length in bytes (1-8).  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> 4.3. these parameters (hex encoded) An implementation should reproduce the output values given the input  <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