Draft: draft-ietf-tls-tlsflags

Commentary: Does it make sense to define a " echo this back " flag ? Just thinking out loud . Argument against it is that clients will just always add that flag / extension ... 
 An empty extension remains as a cheaper option . 
 I 'm not sure that you want to publish a document with a reference ( even if informative ) to the scas draft . Other than that , this is the right way to structure this , provided a couple of issues are resolved . I 've suggestions for each . I proposed some simplifications and clarifications . Along with proposed changes , I think this is good to go .
A server that supports this extension and also supports at least one
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
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.
A server MUST NOT indicate support for any flag-type feature not
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.
Any TLS implementation that intends to propose or indicate support
for a flag extension SHALL send this extension with the relevant bits
set.  It MUST NOT send this extension empty -- with a length of zero.
This specification does not require every flag extension to be
acknowledged.  Acknowledging a flag extension is typically needed to
inform the peer proposing the extension that the other side
understands and supports the extension, but some extensions do not
require this acknowledgement.
A flag proposed by the client in ClientHello (CH) that requires
acknowledgement SHOULD be acknowledged in either ServerHello (SH), in
EncryptedExtensions (EE), in Certificate (CT), or in
HelloRetryRequest (HRR) as the corresponding flag document specifies.
Similarly, a flag proposed by the server in the CertificateRequest
(CR) message that requires acknowledgement SHOULD be acknowledged in
the client's Certificate (CT) message.  A flag proposed by the server
in the NewSessionTicket (NST) message is never acknowledged as there
is not client-side response message.
Multiple flags can be proposed or acknowledged in the same extension.
In all of the above cases, a flag MUST NOT be acknowledged in SH, EE,
CT, or HRR without first having been proposed in CH or CR.
Unsolicited flags may appear only in CH, CR, and NST.  And endpoint
that receives an unsolicited flag in another message (HRR, SH, EE, or
CT) MUST generate a fatal illegal_parameter alert.