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

Commentary: Also fix the build . Some references were a little off . 
 A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users . 
 Ah yes , good point . That should be pointed out explicitly . Will put together a PR after Thanksgiving ( and after is merged since it contains a build fix and I 'm not sure how PRs depending on pieces of other PRs works :-) ) . 
 unless there are any objections once we get this issue squared away I 'll go ahead and issue a WGLC . It 's been marinating long enough . 
 Should be fixed by . 
 THere 's a TODO for reserving " ignore/ " ALPN . 
 are you thinking : Protocol : ignore/1 Identification : 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference : ( This document ) ... Protocol : ignore/10 Identification : 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference : ( This document ) 
 I did n't have a particularly clear picture in my mind , TBH . We 're not sending fake ALPN values or anything right now . ignore/[numbers ] seems fine . Or maybe it would be better to drop the " ignore/ " thing and just use the same two - byte pattern . " ignore/ " makes it look like you should do a prefix check , which is n't really what we want ... 
 PTAL because I think this is really the last " technical " point remaining . 
 not sure what you mean by two - byte pattern . You mean things like " qz " " db " " r$ " etc ? If so , I agree that that is better . 
 Yeah . For the sake of consistency , I figure it could just be the same old 0x?a , 0x?a pattern that everything else does . ( Though they then would n't be ASCII . Could pick some pattern that 's ASCII if that 's preferred . ) 
 i think two random bytes is good ( testing for non - ascii seems greasy as well ) 
 I also prefer the two - byte pattern , since ignore/ might indicate to people that this is somehow meant to be special - cased . 
 Two bytes it is !
The TLS protocol RFC8466 includes several points of extensibility,
including the list of cipher suites and the list of extensions.  The
values in these lists identify implementation capabilities.  TLS
follows a model where one side, usually the client, advertises
capabilities and the peer, usually the server, selects them.  The
responding side must ignore unknown values so that new capabilities
may be introduced to the ecosystem while maintaining
interoperability.
The TLS protocol RFC8446 includes several points of extensibility,
including the list of cipher suites and the list of extensions.  The
values in these lists identify implementation capabilities.  TLS
follows a model where one side, usually the client, advertises
capabilities and the peer, usually the server, selects them.  The
responding side must ignore unknown values so that new capabilities
may be introduced to the ecosystem while maintaining
interoperability.
Finally, this document reserves all ALPN identifiers RFC7301
beginning with the prefix "ignore/".  This corresponds to the seven-
octet prefix: 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x2f.
Draft: draft-ietf-tls-grease-latest

Commentary: Just updating the terminology section to reference  .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119[RFC2119] RFC8174 when, and only when, they appear in all
capitals, as shown here.