Draft: draft-ietf-tls-exported-authenticator

Commentary: 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   at IETF 102 
 So you just wanted to repeat the requirement ? Because that first bit already said no repeats .
An opaque string which identifies the certificate request and
which will be echoed in the authenticator message.  A
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.
An opaque string which identifies the certificate request and
which will be echoed in the authenticator message.  A
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.
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
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.
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
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.
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
provided, the certificate_request_context can be chosen arbitrarily.
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
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.