jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Ripped from RFC 7515 .
Establish Designated Expert pool rules for Specification Required
registries.
Specification Required RFC5226 registry requests are registered after
a three-week review period on the (tbd but maybe tls-reg-
review@ietf.org) mailing list, on the advice of one or more
Designated Experts.  However, to allow for the allocation of values
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.
Registration requests sent to the mailing list for review SHOULD use
an appropriate subject (e.g., "Request to register value in TLS bar
registry").
Within the review period, the Designated Experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA.  Denials SHOULD include an explanation and, if
applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution.
Criteria that SHOULD be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
useful only for a single application, and whether the registration
description is clear.
IANA MUST only accept registry updates from the Designated Experts
and SHOULD direct all requests for registration to the review mailing
list.
It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using
this specification, in order to enable broadly informed review of
registration decisions.  In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert SHOULD defer to the judgment of the other
Experts.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Adding instructions for the RFC editor to delete the sentence that notes the algorithms defined in RFC 5289 as these algorithms will be standards track at or before the time this draft gets to the RFC editor .
RFC EDITOR: Please delete the sentence beginning with "The notable
exception ..." after RFC 5289 has been promoted to Proposed Standard.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Added the guidelines from RFC 5705 
 Need to add designated expert instructions for exporters like we did for ExtensionType ,   , and ClientCertificateType Identifiers registries . 
 Also addressed by .
Add designated expert intructions as notes in the TLS
ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType
Identifiers, and TLS Exporter Label registries to inform users
about what to expect from the designated expert.
Add designated expert instructions as notes in the TLS
ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType
Identifiers, and TLS Exporter Label registries to inform users
about what to expect from the designated expert.
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
Suite, and TLS Exporters Label registries.  Initial values marked
"Yes" are specified in IETF Standards Track documents; all others
are marked "No".  This new column is intened to alter the
incorrect perception that getting a code point somehow legitimizes
the extesion, cipher suite/algorithm, or exporter.
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
Suite, and TLS Exporters Label registries.  Initial values marked
"Yes" are specified in IETF Standards Track documents; all others
are marked "No".  This new column is intended to alter the
incorrect perception that getting a code point somehow legitimizes
the extension, cipher suite/algorithm, or exporter.
Note(3): The designated expert RFC5226 only ensures that the
specification is publically available.
Note(3): The designated expert RFC5226 only ensures that the
specification is publicly available.
Note: The designated expert RFC5226 only ensures that the
specification is publically available.
Note: The designated expert RFC5226 only ensures that the
specification is publicly available.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Need to update summary to , at a minimum , reflect that the following is now in the draft : Added " Recommended " column to TLS ExtensionType Values , TLS   , and TLS Exporters registries to clearly indicate which values are specified in IETF   documents .
Add "TLS" to registries' names for consistency with other TLS-
related registries.
Add the designated expert intructions as a note to the TLS
ExtensionType Values, TLS Cipher Suite, and TLS
ClientCertificateType Identifiers registries to inform users of
the registry.
Add "TLS" to registries' names for consistency amongst TLS-related
registries.
Add designated expert intructions as notes in the TLS
ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType
Identifiers, and TLS Exporter Label registries to inform users
about what to expect from the designated expert.
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
Suite, and TLS Exporters Label registries.  Initial values marked
"Yes" are specified in IETF Standards Track documents; all others
are marked "No".  This new column is intened to alter the
incorrect perception that getting a code point somehow legitimizes
the extesion, cipher suite/algorithm, or exporter.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Exporters are another registry that could use an " IETF Recommended " column .
Add missing entry to the TLS Alert Registry for the
no_application_protocol alert defined in RFC7301.
IANA is to also to add a "Recommended" column to the TLS Exporter
Label registry.  The table that follows has been generated by marking
Standards Track RFCs as "Yes" and all others as "No".  Future
exporters MUST define the value of this column.  A Standards Track
document RFC5226 is required to register an extension with the value
"Yes".
Draft: draft-ietf-tls-iana-registry-updates

Commentary: This PR and 
 ship it 
 From the draft : Remove one " are " from " are are reserved " . 
 Remove the " it " from " can not it " in the text below : 
 From the Introduction section : As far as I can see the above ought to be :
Rename the SessionTicket TLS to session_ticket to match the
nomenclature for the other extensions' names.
Rename the SessionTicket TLS extension to session_ticket to match
the nomenclature for the other extensions' names.
Note(1): Although TLS 1.3 uses the same cipher suite space as
previous versions of TLS, TLS 1.3 cipher suites are defined
differently, only specifying the symmetric ciphers, and cannot it
be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites
cannot be used with TLS 1.3.
Note(1): Although TLS 1.3 uses the same cipher suite space as
previous versions of TLS, TLS 1.3 cipher suites are defined
differently, only specifying the symmetric ciphers, and cannot be
used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites
cannot be used with TLS 1.3.
Values in the range 0-223 are assigned via Specification Required
RFC5226.  Values 224-255 are are reserved for Private Use.
Values in the range 0-223 are assigned via Specification Required
RFC5226.  Values 224-255 are reserved for Private Use.