Original text:
may appear in ClientHello messages from clients which are offering prior versions of TLS).  4.2.5. The "post_handshake_auth" extension is used to indicate that a client authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). <del> 4.3.2.1. The "oid_filters" extension allows servers to provide a set of OID/ value pairs which it would like the client's certificate to match. This extension MUST only be sent in the CertificateRequest message. %%% Server Parameters Messages A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded X690 format.  Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert.  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs. This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </del> 4.4. As discussed in protocol-overview, TLS generally uses a common set of If the certificate_extensions list in the CertificateRequest message was non-empty, the end-entity certificate MUST match the <del> extension OIDs recognized by the client, as described in certificate-request. </del>  Note that, as with the server certificate, there are certificates that use algorithm combinations that cannot be currently used with

Reviewer comments:
This was the one extension that wasn't in the extensions section, which made it hard to find. Note I've also removed the indent on the trailing paragraphs to avoid the walloftext problem with the existing text.
Does the part that says need to be updated to point to this new location instead of {{certificate-request}}?
Good catch. Fixed.
lgtm
merge this when ready

Revised text:
may appear in ClientHello messages from clients which are offering prior versions of TLS). <ins> 4.2.4.1. The "oid_filters" extension allows servers to provide a set of OID/ value pairs which it would like the client's certificate to match. This extension MUST only be sent in the CertificateRequest message. %%% Server Parameters Messages A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded X690 format.  Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert. PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs. This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension.  The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </ins> 4.2.5. The "post_handshake_auth" extension is used to indicate that a client authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth).  4.4. As discussed in protocol-overview, TLS generally uses a common set of If the certificate_extensions list in the CertificateRequest message was non-empty, the end-entity certificate MUST match the  <ins> extension OIDs recognized by the client, as described in oid- filters. </ins> Note that, as with the server certificate, there are certificates that use algorithm combinations that cannot be currently used with