Original text:
9.2.2. A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher <del> suites that are listed in BadCipherSuites. </del>  Endpoints MAY choose to generate a ConnectionErrorHandler of type <del> if one of the prohibited cipher suites are negotiated.  A deployment that chooses to use a prohibited cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </del>  Implementations MUST NOT generate this error in reaction to the <del> negotiation of a cipher suite that is not in the prohibited list. Consequently, when clients offer a cipher suite that is not prohibited, they have to be prepared to use that cipher suite with </del>  HTTP/2. <del> The effect of prohibiting these cipher suites is that TLS 1.2 deployments could have non-intersecting sets of available cipher suites, since the prohibited set includes the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </del>  Note that clients might advertise support of cipher suites that are <del> prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2 and support only prohibited cipher suites.  This allows servers to select HTTP/1.1 with a cipher suite that is prohibited for HTTP/2.  However, this can result in HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. </del>  10.

Reviewer comments:
Kathleen Moriarty's IESG review noted some confusion that I think derived from the use of the word "prohibited" in relation to the cipher suite black list.

Revised text:
9.2.2. A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher  <ins> suites that are listed in the BadCipherSuites. </ins> Endpoints MAY choose to generate a ConnectionErrorHandler of type  <ins> if one of the cipher suites from the black list are negotiated.  A deployment that chooses to use a black-listed cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </ins> Implementations MUST NOT generate this error in reaction to the  <ins> negotiation of a cipher suite that is not on the black list. Consequently, when clients offer a cipher suite that is not on the black list, they have to be prepared to use that cipher suite with </ins> HTTP/2.  <ins> The black list includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non- intersecting sets of permitted cipher suites.  To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </ins> Note that clients might advertise support of cipher suites that are  <ins> on the black list in order to allow for connection to servers that do not support HTTP/2.  This allows servers to select HTTP/1.1 with a cipher suite that is on the HTTP/2 black list.  However, this can result in HTTP/2 being negotiated with a black-listed cipher suite if the application protocol and cipher suite are independently selected. </ins> 10.