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

Commentary: An open issue was whether to close the HashAlgorithms and SignatureAlgorithms registries or just reserve the values and point to the new 1.3 schemes . WRT opening a closed registry , IANA told me that opening a closed registry required another RFC or if we put in the IANA considerations section IESG Approval . With that info and the fact that at least one person was like " woah wait I might need to register some algorithms for TLS1.2 " , I do n’t really see the point in closing the registry so I propose that we leave it as is , but that we update the text as noted in the PR to explicit point to the  registry . 
 I think that reserving them is the right thing for now . TLS 1.2 and earlier will take a while to disappear , so the ability to assign more values if there is a huge surprise seems prudent . 
 PTAL
The values in this registry are only applicable to (D)TLS protocol
versions prior to 1.3.
The values in this registry are only applicable to (D)TLS protocol
versions prior to 1.3.  (D)TLS 1.3 and later versions' values are
registered in the TLS SignatureScheme registry.
Draft: draft-ietf-tls-iana-registry-updates

Commentary:   and SignatureAlgorithm warning . 
 Thanks !
Cryptographic algorithms and parameters will be broken or weakened
over time.  Blindly implementing cipher suites listed here is not
advised.  Implementers and users need to check that the
cryptographic algorithms listed continue to provide the expected
level of security.
Cryptographic algorithms and parameters will be broken or weakened
over time.  Blindly implementing the cryptographic algorithms
listed here is not advised.  Implementers and users need to check
that the cryptographic algorithms listed continue to provide the
expected level of security.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Looks good 
 I think the TLS Certificate Type section should explicitly list the values for which " specification required " applies ( and for which " reserved for private use " continues to apply ) .
Experience has shown that the IETF Consensus registry policy for TLS
Certificate Types is too strict.  Based on WG consensus, the decision
was taken to change registration policy to Specification Required
RFC8126 while reserving a small part of the code space for
experimental and private use.  Therefore, IANA [SHALL add/has added]
a "Recommended" column to the registry.  X.509 and Raw Public Key are
"Yes".  All others are "No".  In order to register an extension with
the value "Yes", a Standards Track document RFC8126 is REQUIRED.
Future Certificate Types MUST define the value of this column.  A
Standards Track document RFC8126 is REQUIRED to register an entry
with the value "Yes".  IESG Approval is REQUIRED for a Yes->No
transition.
Values with the first byte in the range 0-223 (decimal) are
assigned via Specification Required RFC8126.  Values with the
first byte 224-255 (decimal) are reserved for Private Use RFC8126.
Add a "Recommended" column to the registry.  X.509 and Raw Public
Key are "Yes".  All others are "No".  In order to register an
extension with the value "Yes", a Standards Track document RFC8126
is REQUIRED.  Future Certificate Types MUST define the value of
this column.  A Standards Track document RFC8126 is REQUIRED to
register an entry with the value "Yes".  IESG Approval is REQUIRED
for a Yes->No transition.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: PTAL 
 LGTM
This document describes a number of changes to (D)TLS IANA registries
that range from adding notes to the registry all the way to changing
the registration policy.  These changes were mostly motivated by WG
review of the (D)TLS-related registries undertaken as part of the
TLS1.3 development process.  This document updates many (D)TLS RFCs
(see updates header).
This document describes a number of changes to Transport Layer
Security and Datagram Transport Layer Security ((D)TLS) IANA
registries that range from adding notes to the registry all the way
to changing the registration policy.  These changes were mostly
motivated by WG review of the (D)TLS-related registries undertaken as
part of the TLS1.3 development process.  This document updates many
(D)TLS RFCs (see updates header).
This document instructs IANA to make changes to a number of (D)TLS-
related IANA registries.  These changes were almost entirely
motivated by the development of TLS1.3 I-D.ietf-tls-tls13.
This document instructs IANA to make changes to a number of Transport
Layer Security and Datagram Transport Layer Security ((D)TLS) related
IANA registries.  These changes were almost entirely motivated by the
development of TLS1.3 I-D.ietf-tls-tls13.
The instructions in this document add a Recommended column to many of
the TLS registries to indicate parameters that are generally
recommended for implementations to support.  Adding a recommended
parameter to a registry or updating a parameter to recommended status
requires standards action.  Not all parameters defined in standards
track documents need to be marked as recommended.
If an item is marked as not recommended it does not necessarily mean
that it is flawed; rather, it indicates that either the item has not
been through the IETF consensus process, has limited applicability,
or is intended only for specific use cases.
The instructions in this document add a Recommended column with a
value of YES or NO to many of the (D)TLS registries to indicate
parameters that are generally recommended for implementations to
support.  Adding a recommended parameter to a registry or updating a
parameter to recommended status requires standards action.  Not all
parameters defined in standards track documents need to be marked as
recommended.
If an item is not marked as recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process, has limited applicability,
or is intended only for specific use cases.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: PTAL 
 LGTM - ‘ twas just a comment anyway . W I do n't think the execution is relevant when it was obviously a bad idea in the first place . This is like putting rabid weasels in your pants , and later expressing regret at having chosen those particular rabid weasels and that pair of pants . ---maf
If an item is marked as not recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process, has limited applicability,
or is intended only for specific use cases.
If an item is marked as not recommended it does not necessarily mean
that it is flawed; rather, it indicates that either the item has not
been through the IETF consensus process, has limited applicability,
or is intended only for specific use cases.
Experts are to verify that there is in fact a publicly available
standard.  An Internet Draft that is posted and never published or
a standard in another standards body, industry consortium,
university site, etc. suffices.
Experts are to verify that there is in fact a publicly available
specification.  An Internet Draft that is posted and never
published or a specification in another standards body, industry
consortium, university site, etc. suffices.
Extensions marked as "Yes" are those allocated via Standards Track
RFCs.  Extensions marked as "No" are not.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: let me know if you think this looks good . 
 I think this fixes it
Experts are to verify that there is in fact a publicly available
standard.
Experts are to verify that there is in fact a publicly available
standard.  An Internet Draft that is posted and never published or
a standard in another standards body, industry consortium,
university site, etc. suffices.
The designated expert RFC8126 ensures that the specification is
publicly available.  The expert also verifies that the label is a
string consisting of printable ASCII characters beginning with
"EXPORTER".  IANA MUST also verify that one label is not a prefix
of any other label.  For example, labels "key" or "master
secretary" are forbidden.
The designated expert RFC8126 ensures that the specification is
publicly available.  An Internet Draft that is posted and never
published or a standard in another standards body, industry
consortium, university site, etc. suffices.  The expert also
verifies that the label is a string consisting of printable ASCII
characters beginning with "EXPORTER".  IANA MUST also verify that
one label is not a prefix of any other label.  For example, labels
"key" or "master secretary" are forbidden.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: let me know what you think . 
 I.e. , if you actually deploy on the Internet with these experimental code points , and you run into someone using the same code point , you 're going to have a bad day . For widespread experiments , we should really be using temporary reservations of some kind instead . 
 How about we add the following note everywhere we private use : NOTE : : As specified in { { RFC5226 } } , assignments made in the Private Use space " are not generally useful for broad interoperability . " It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur ( within the intended scope of use ) . For widespread experiments , temporary reservations are available . 
 LGTM . 
 Addressed by .
The following is from I-D.ietf-tls-tls13 and is included here to
ensure aligment between these specifications.
IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", "post_handshake_auth",
and "signature_algorithms_certs", extensions with the values
defined in this document and the Recommended value of "Yes".
IANA [SHALL update/has updated] this registry to include a "TLS
1.3" column which lists the messages in which the extension may
appear.  This column [SHALL be/has been] initially populated from
the table in Section 4.2 of I-D.ietf-tls-tls13 with any extension
not listed there marked as "-" to indicate that it is not used by
TLS 1.3.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Add certtype and usermapping to the orphaned list .
The following extensions are only applicable to (D)TLS protocol
versions prior to 1.3: trusted_ca_keys, truncated_hmac,
ec_point_formats, srp, status_request_v2, encrypt_then_mac,
extended_master_secret, session_ticket, and renegotiation_info.
These extensions are not applicable to (D)TLS 1.3.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Addresses and . 
 CCM_8 has a significantly truncated authentication tag that represents a security trade - off that may not be appropriate for general environment . 
 I think not . 
 LGTM . Can you send me a PR for the TLS 1.3 spec .
CCM_8 cipher suites are not marked as Recommended.  These cipher
suites have a significantly truncated authentication tag that
represents a security trade-off that may not be appropriate for
general environments.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Comment from Rich $ alz .
The instructions in this document add a recommended column to many of
the TLS registries to indicate parameters that are generally
recommended for implementations to support.  Adding a recommended
parameter to a registry or updating a parameter to recommended status
requires standards action.
Not all parameters defined in standards track documents need to be
marked as recommended.
If an item is marked as not recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process or the item has limited
applicability to specific cases.
The instructions in this document add a recommended column to many of
the TLS registries to indicate parameters that are generally
recommended for implementations to support.  Adding a recommended
parameter to a registry or updating a parameter to recommended status
requires standards action.  Not all parameters defined in standards
track documents need to be marked as recommended.
If an item is marked as not recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process, has limited applicability,
or is intended only for specific use cases.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Addresses and . 
 Seems like we should add a security consideration about the expert and how much review they 're going to do . 
 We probably need to say something more in the security considerations . What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups . There must be others .
Designated experts ensure the specification is publicly available.
They may provide more in depth reviews.  Their review should not be
taken as an endorsement of the cipher suite, extension, supported
group, etc.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: PR adds section to describe recommended to
The instructions in this document add a recommended column to many of
the TLS registries to indicate parameters that are generally
recommended for implementations to support.  Adding a recommended
parameter to a registry or updating a parameter to recommended status
requires standards action.
Not all parameters defined in standards track documents need to be
marked as recommended.
If an item is marked as not recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process or the item has limited
applicability to specific cases.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: This fixes a typo in the security considerations section and adds some additional text . 
 We probably need to say something more in the security considerations . What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups . There must be others .
The change to Specification Required from IETF Review lowers the
amount of review provided by the WG for cipher suites and supported
groups.  This change reflects reality in that the WG essentially
provided no cryptographic review of the cipher suites or supported
groups.  This was espcecially true of national cipher suites.
The change to Specification Required from IETF Review lowers the
amount of review provided by the WG for cipher suites and supported
groups.  This change reflects reality in that the WG essentially
provided no cryptographic review of the cipher suites or supported
groups.  This was especially true of national cipher suites.
Recommended algorithms regarded as secure for general use at the time
of registration, however, cryptographic algorithms and parameters
will be broken or weakened over time.  It is possible that the
recommended status in the registry lags behind the most recent
advances in cryptanalysis.  Implementers and users need to check that
the cryptographic algorithms listed continue to provide the expected
level of security.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Possibly addresses . 
 We probably need to say something more in the security considerations . What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups . There must be others .
The authors are fairly certain that there are no security
considerations for this document.
The change to Specification Required from IETF Review lowers the
amount of review provided by the WG for cipher suites and supported
groups.  This change reflects reality in that the WG essentially
provided no cryptographic review of the cipher suites or supported
groups.  This was espcecially true of national cipher suites.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Addresses . 
 MT suggested that we add the same warnings we have for cipher suites and named groups to all crypto - related registries . The two remaining crypt - related registries are HashAlgorithm and SignatureAlgorithm and both are being orphaned . Despite the fact they are being orphaned we should still add similar text . Are there any others that should include the warning ? 
 merged
WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing cipher suites listed here
is not advised.  Implementers and users need to check that the
cryptographic algorithms listed continue to provide the expected
level of security.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: This adds the designated expert note to supported groups to address issue 32 
 Just setting this up to auto address . 
 I believe specification required still involves a designated expert review . 
 Yes expert review is implied by specification required , but you 're right we should also include the same note about the experts just making sure it 's publicly available .
The designated expert RFC8126 only ensures that the specification
is publicly available.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: I 'm fairly sure that I sent these in already . Was there a regression ? The current build has lines that are insanely long . This corrects that ( and removes a warning caused by an open bracket ) . 
 I thought I fixed it , but I guess I 'd missed it . I 've got a fairly long rewrite that I hope to land early next that I think also addresses these . 
 Hoping that this is fixed via , which is pretty big set of editorial changes .
Note: The designated expert RFC5226 only ensures that the
specification is publicly available.
The designated expert RFC5226 only ensures that the specification
is publicly available.
RFC5705 defines keying material exporters for TLS in terms of the
TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus
requiring a new construction.  The exporter interface remains the
same, however the value is computed different.
The designated expert RFC5226 ensures that the specification is
publicly available.  The expert also verifies that the label is a
string consisting of printable ASCII characters beginning with
"EXPORTER".  IANA MUST also verify that one label is not a prefix
of any other label.  For example, labels "key" or "master
secretary" are forbidden.
The following extensions are only applicable to (D)TLS protocol
vesions prior to 1.3: trusted_ca_keys, truncated_hmac,
ec_point_formats, srp, status_request_v2, encrypt_then_mac,
extended_master_secret, session_ticket, and renegotiation_info.
These are not applicable to DTLS 1.3.
Note: Value 0 (NULL) is the only value in this registry applicable
to (D)TLS protocol version 1.3 or later.
Note: The values in this registry are only applicable to (D)TLS
protocol versions prior to 1.3.
Value 0 (NULL) is the only value in this registry applicable to
(D)TLS protocol version 1.3 or later.
The values in this registry are only applicable to (D)TLS protocol
versions prior to 1.3.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: This probably ca n't be used , so we should reserve it .
The value 0 (0x0000) is to be marked as reserved.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: This text is taken from TLS1.3 . The point is to reserve the remaining values as a really big hint to " not look here , go look over there " .
IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to
list values 7-223 as "Reserved" and the TLS SignatureAlgorithm
registry to list values 4-223 as "Reserved".
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Need a " Recommended " column for the TLS Certificate Types registry .
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
Suite, TLS Supported Groups, 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.
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
Suite, TLS Certificate Types, TLS Supported Groups, 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.
Add a "Recommended" column to the registry.  X.509 and Raw Public Key
are "Yes".  All others are "No".  A Standards Track document RFC5226
is required to register a certificate type with the value "Yes".
Draft: draft-ietf-tls-iana-registry-updates

Commentary: trustedcakeys and ecpointformats are also orphaned .
Update the "References" in the TLS Compression Method Identifiers,
TLS Hash Algorithm RFC5246 and TLS SignatureAlgorithm registries
to also refer to this document.
Update the "References" in the TLS Compression Method Identifiers,
TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to
also refer to this document.
Draft: draft-ietf-tls-iana-registry-updates

Commentary: " Supported Groups " also needed a " Recommended " column . 
 We 've also got FF DHE groups in this registry . Got a feeling for which should be " Yes " ? 
 Much like the ciphers we need to add a " recommended " column for curves / groups . Adding this column was suggested during review of 4492bis .
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.
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
Suite, TLS Supported Groups, 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.
This document proposes no changes to the EC Curve Type, EC Point
Format, and Supported Groups Registries (see I-D.ietf-tls-
rfc4492bis).
Add a "Recommended" column with a "Yes" for secp256r1, secp384r1,
x25519, and x448 while all others are "No".  These "Yes" groups are
taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls-
rfc4492bis, which is standards track, are not marked as "Yes"; these
groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of
TLS I-D.ietf-tls-tls13.  A Standards Track document RFC5226 is
required to register an entry with the value "Yes".
Draft: draft-ietf-tls-iana-registry-updates

Commentary: Addresses . 
 Also addresses . 
 LGTM 
 We need to update the registry 's reference to point to this document if we require new CS definitions to indicate whether the Recommended column is Yes or No ( see ) . 
 The cipher suite " recommended " column needs to include something along the line of the following : Future cipher suites MUST define the value of the Recommended column . A Standards Track document [ RFC5226 ] is required to register a cipher suite with the value “ Yes ” .
Add a "Recommended" column to the cipher suite registry.  The
cipher suites that follow in the two tables are marked as "Yes".
All other cipher suites are marked as "No".
Add a "Recommended" column to the cipher suite registry.  The
cipher suites that follow in the two tables are marked as "Yes".
All other cipher suites are marked as "No".  Future cipher suites
MUST define the value of the Recommended column.  A Standards
Track document RFC5226 is required to register a cipher suite with
the value "Yes".
Update the reference for this registry to also point to this
document.