jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-tlsflags

Commentary: This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment . 
 Well , I think of this as being the request extension . I can live with this if it 's the WG consensus , but it seems like it would be useful to be able to say " I support largeish extension X " ( we already have some such extensions ) and it would be kind of sad if that took 4 bytes . 
 Seems strange to have to state this , but that 's OK . Do you want to explain why ? That is , because this results in a " response " extension appearing without a " request " extension , which is not permitted .
For a flag that does require a response, the only proper response is
the same flag in a flags extension.  This extension MUST NOT be used
to specify extensions where the response is a proper extension with
content.
Draft: draft-ietf-tls-tlsflags

Commentary: To solve issue 
 RFC8446 4.2.10 requires that : This extension does not ( as far as I can see ) do that . I think the text in tls - flags should prevaricate on this topic , because really it 's an encoding framework for trivial extensions ( that themselves need to define their interaction with 0 - RTT . ) 
 Created a PR . Let me know if this is satisfactory . 
 assume this one can be closed based on being merged ?
The 0-RTT handshake, defined in section 2.3 of RFC8446, has a
ClientHello message, a ServerHello message, and an
EncryptedExtensions message.  Those can include the tls_flags
extension just as they can in a regular handshake.
Future flag extensions MUST define their interaction with 0-RTT, just
as other extensions are required to.
Draft: draft-ietf-tls-tlsflags

Commentary: This is to address a comment by   on the mailing list . To quote :
An implementation that receives an invalid tls_flags extension MUST
terminate the TLS handshake with a fatal illegal_parameter alert.
Draft: draft-ietf-tls-tlsflags

Commentary: Show the initial registry value is a decimal number rather than a hex number . 
 LGTM .
Flags 8-31 are for standards-track documents that the experts
believe will see wide adoption among either all users of TLS or a
significant group of TLS users.  For example, an extension that
will be used by all web clients or all smart objects.
Flags 8-31 are for standards-track documents that the experts
believe will see wide adoption among either all users of TLS or a
significant group of TLS users.  For example, an extension that
will be used by all web clients or all smart objects.  The only
entry in the initial registry is from this range.
Draft: draft-ietf-tls-tlsflags

Commentary: All messages that carry extensions can have a tls_flags extension : CH , SH , EE ,  , NST 
 can you please respond to the comments above ? 
 Ping :-) 
 Done . 
 I might have framed this slightly differently , but this accurately captures the outcome of the discussion . Thanks for doing this .
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 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.
A server MUST NOT indicate support for any flag-type feature not
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.
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.
Draft: draft-ietf-tls-tlsflags

Commentary: Provide guidance on what flag should be allocated to what extension , based on the likelihood of that extension being widely used .
This extension allows up to 2040 flags.  However, they are not all
the same, because the length of the extension is determined by the
highest set bit.
We would like to allocate the flags in such a way that the typical
extension is as short as possible.  The scenario we want to guard
against is that in a few years some extension is defined that all
implementations need to support and that is assigned a high number
because all of the lower numbers have already been allocated.  An
example of such an extension is the Renegotiation Indication
Extension defined in RFC5746.
Flags 0-7 are reserved for documents coming out of the TLS working
group with a specific request to assign a low number.
Flags 8-31 are for standards-track documents that the experts
believe will see wide adoption among either all users of TLS or a
significant group of TLS users.  For example, an extension that
will be used by all web clients or all smart objects.
Flags 32-63 are for other documents, including experimental, that
are likely to see significant adoption.
Flags 64-79 are not to be allocated.  They are for reserved for
private use.
Flags 80-2039 can be used for temporary allocation in experiments,
for flags that are likely to see use only in very specific
environments, for national and corporate extensions, and as
overflow, in case one of the previous categories has been
exhausted.