Original text:
of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by <del> the client.  The intersection operation MAY be implemented as a bitwise AND.  The server may need to send two tls_flags extensions, one in the ServerHello and the other in the EncryptedExtensions message.  It is up to the document for the specific feature to determine whether support should be acknowledged in the ServerHello or the EncryptedExtensions message. </del>  A server MUST NOT indicate support for any flag-type feature not <del> previously indicated by the client.  It MUST NOT include this extension in either message (ServerHello or EncryptedExtensions) if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. </del>  4. extensions.  It does not send in the clear any information that would otherwise be sent encrypted, nor vice versa.  For this reason this extension is neutral as far as security is concerned. 

Reviewer comments:
All messages that carry extensions can have a tls_flags extension: CH, SH, EE, Cert, NST
NAME can you please respond to the comments above?
Ping NAME :-)
Done.
I might have framed this slightly differently, but this accurately captures the outcome of the discussion. Thanks for doing this.

Revised text:
of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by  <ins> the client.  The intersection operation may be implemented as a bitwise AND.  The server may need to send multiple tls_flags extensions, up to one in each of the four response messages that may carry extensions: ServerHello (SH), EncryptedExtensions (EE), Certificate (CT), and HelloRetryRequest (HRR).  It is up to the document for the specific feature to determine which of these should be used to acknowledge support. </ins> A server MUST NOT indicate support for any flag-type feature not  <ins> previously indicated by the client in the ClientHello in any response message.  It MUST NOT include this extension in any of the four messages if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. A server MAY indicate support for flag-type features in a flags extension of CertificateRequest (CR).  Flag-type extensions that have been indicated in CR (and only such extensions) MAY be also be present in a flags extension of the Certificate (CT) message sent by the client.  However, a client MUST NOT indicate support for any flag-type feature in a Certificate message that was not previously indicated by the server in its CertificateRequest message. A server MAY indicate support for flag-type features in a flags extension of NewSessionTicket (NST).  This message has no client-side response. In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket. </ins> 4. extensions.  It does not send in the clear any information that would otherwise be sent encrypted, nor vice versa.  For this reason this extension is neutral as far as security is concerned. <ins> Extension authors should be aware that acknowledging flags in a tls_flags extension of the ServerHello and HelloRetryRequest messages expose this response to passive observers.  Unless there is a special reason to place the response in the ServerHello, most flags should go in other (encrypted) messages. </ins>