Original text:
As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous <del> unacknowledged packet numbers, including the new packet. For example, if an endpoint has received an acknowledgment for packet 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe. </del>  At a receiver, protection of the packet number is removed prior to recovering the full packet number.  The full packet number is then Once header protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet.  The next expected packet is the highest received packet <del> number plus one.  For example, if the highest successfully authenticated packet had a packet number of 0xa82f30ea, then a packet containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. Example pseudo-code for packet number decoding can be found in sample-packet-number-decoding. </del>  17.2.

Reviewer comments:
I took some liberties with data types here, but... pseudocode. I do wonder if the slice notation is sufficiently clear; I was hesitant to just do bit-shifts and masks because the number of bytes returned is key. An alternative would be simply to return the number of bytes, I suppose.
bit more than the base-2 logarithm of the number of contiguous unacknowledged packet numbers, including the new packet. That is really hard to parse. 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe. and so is that. Indeed I found the remaining paras of the section difficult to follow.
I agree that first sentence is hard to parse.
I also agree regarding the first. As this is an alternative description, and I don't have anything better to offer, I plan not to change anything unless someone offers something good. The second seems fine.
I wonder if the real takeaway here is that these "examples in passing" assume the reader is deeply following along with the algorithm in their head; I know I don't, but I'm also not implementing packetization. We already have an appendix that illustrates packet number decoding; perhaps we should move one or both paragraphs to an appendix that illustrates selecting an encoding, with these as the examples. Reading the rest of the section, is "protection of the packet number" the term we've used elsewhere? Shouldn't that be "header protection," perhaps with a cross-ref to -tls?

Revised text:
As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous  <ins> unacknowledged packet numbers, including the new packet.  Pseudo-code and examples for packet number encoding can be found in sample- packet-number-encoding. </ins> At a receiver, protection of the packet number is removed prior to recovering the full packet number.  The full packet number is then Once header protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet.  The next expected packet is the highest received packet  <ins> number plus one.  Pseudo-code and an example for packet number decoding can be found in sample-packet-number-decoding. </ins> 17.2.