Original text:
An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A <del> certificate_request_context value MUST NOT be repeated for multiple authenticator requests generated by the same party within the scope of a connection (thus preventing replay of authenticators).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators.  This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. </del>  The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del>  4.2.1. The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is <del> provided, the certificate_request_context can be chosen arbitrarily. </del>  The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version

Reviewer comments:
NAME The crc can be derived in two places: the authenticator request and the unsolicited authenticator. I want to make sure the requirement is clear in both places.
Issue raised by Jonathan Hoyland at IETF 102
So you just wanted to repeat the requirement? Because that first bit already said no repeats.

Revised text:
An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A  <ins> certificate_request_context value MUST be unique for each authenticator request within the scope of a connection (preventing replay and context confusion).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators.  This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. </ins> The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator  <ins> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1. The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is  <ins> provided, the certificate_request_context can be chosen arbitrarily but MUST be unique within the scope of the connection and be unpredictable to the peer. </ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version