jiebi/CodeConvo huggingface dataset:
Change:
A few more typos I found while I was reading this I-D.
Thanks again!

Discussion:
inspect a copy of the information, usually mirrored by an optical splitter, making it an ideal pairing for DPI and Protocol Identification Weaver-2009 (this asynchronous version of a MITM is <del> ofen called a Man-on-the-Side (MOTS)).  RST Packet Injection also has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.  The </del> <ins> often called a Man-on-the-Side (MOTS)).  RST Packet Injection also has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.  The </ins> difficult part of RST Packet Injection is spoofing "enough" correct information to ensure one end-point accepts a RST packet as legitimate; this generally implies a correct IP, port, and (TCP)

As the name implies, sometimes manpower is the easiest way to figure out which content to block.  Manual Filtering differs from the common <del> tactic of building up blacklists in that is doesn't necessarily </del> <ins> tactic of building up blacklists in that it doesn't necessarily </ins> target a specific IP or DNS, but instead removes or flags content. Given the imprecise nature of automatic filtering, manually sorting through content and flagging dissenting websites, blogs, articles and
Change:
TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key. TLS 1.2 removed this restriction. Since RFC 4492 predated TLS 1.2 it reflected the same restriction. Here we remove it.

Discussion:
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message <del> must be computed with the corresponding RSA private key.  The server certificate MUST be signed with RSA. </del> <ins> must be computed with the corresponding RSA private key. </ins> 2.3.

resultant shared secret as the premaster secret.  All ECDH calculations are performed as specified in alg_computes. <del> Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DHE_DSS, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used elsewhere in the certificate chain.  (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices.  However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.) </del> <ins> This specification does not impose restrictions on signature schemes used anywhere in the certificate chain.  The previous version of this document required the signatures to match, but this restriction, originating in previous TLS versions is lifted here as it had been in RFC 5246. </ins> 3.

3.1. To use this authentication mechanism, the client MUST possess a <del> certificate containing an ECDSA-capable public key and signed with ECDSA. </del> <ins> certificate containing an ECDSA-capable public key. </ins> The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify
Change:
See Sean Turner's message IETF review is too onerous - use "specification required" instead.

Discussion:
5.1.1. <del> RFC 4492 defined 25 different curves in the NamedCurve registry for use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA. The end result is as follows: </del> <ins> RFC 4492 defined 25 different curves in the NamedCurve registry (now renamed the "Supported Groups" registry, although the enumeration below is still named NamedCurve) for use in TLS.  Only three have seen much use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.  It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration.

RFC4492, the predecessor of this document has already defined the IANA registries for the following: <del> NamedCurve </del> <ins> Supported Groups </ins> ECPointFormat ECCurveType For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight <del> values (ECPointFormat and ECCurveType) reserved for Private Use.  Any additional assignments require IETF Review. </del> <ins> values (ECPointFormat and ECCurveType) reserved for Private Use.  The policy for any additional assignments is "Specification Required". The previous version of this document required IETF review. </ins> <del> NOTE: IANA, please update the registries to reflect the new policy name. </del> <ins> NOTE: IANA, please update the registries to reflect the new policy. </ins> NOTE: RFC editor please delete these two notes prior to publication.
Change:
Should remove the "TBD2" after ecdh_x448.
Looks good to me. Thanks.

Discussion:
IANA is requested to assign two values from the NamedCurve registry with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference.  IANA has already assigned the value 29 to <del> ecdh_x25519, and the value 30 to ecdh_x448(TBD2). </del> <ins> ecdh_x25519, and the value 30 to ecdh_x448. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.
Change:
Removed two paragraphs and a table full of motivation about why ECC is great. In 2016 this is no longer needed. ECC is already mainstream.
+1

Discussion:
1. <del> Elliptic Curve Cryptography (ECC) has emerged as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is illustrated in the following table, based on Lenstra_Verheul, which gives approximate comparable key sizes for symmetric- and asymmetric- key cryptosystems based on the best-known algorithms for attacking them. Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments. </del> This document describes additions to TLS to support ECC, applicable to TLS versions 1.0 RFC2246, 1.1 RFC4346, and 1.2 RFC5246.  The use of ECC in TLS 1.3 is defined in I-D.ietf-tls-tls13, and is explicitly
Change:
if both draft-ietf-tls-iana-registry-updates and this draft add TLS to the registry names then all the registry will have a consistent naming scheme.
Ship it
Shipped
LGTM

Discussion:
ECPointFormat ECCurveType <ins> IANA is requested to prepend "TLS" to the names of the previous three registries. </ins> For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  The

Added TLS 1.2 to references. Moved RFC 4492 authors to acknowledgements. Removed list of required reading for ECC. <ins> Prepended "TLS" to the names of the three registries defined in the IANA Considerations section. </ins>
Change:
Use initialism consistently in the Introduction Mention EdDSA in addition to ECDSA as a signature scheme
lgtm

Discussion:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-14 </del> <ins> draft-ietf-tls-rfc4492bis-15 </ins> Abstract

out of scope for this document.  In particular, this document defines: <del> the use of the Elliptic Curve Diffie-Hellman key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA certificates for authentication of TLS peers. </del> <ins> the use of the ECDHE key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA and EdDSA signatures for authentication of TLS peers. </ins> The remainder of this document is organized as follows. ecdh provides an overview of ECC-based key exchange algorithms for TLS. clientauth
Change:
RFC 4492 called SHA-1 the "default" hash for ECDSA, because that was the only hash defined in X9.62 at the time. The new X9.62 (new being a relative term - it's from 2005) defines all the SHA-2 hashes as well. We now make the use of secure hashes a MUST and we call out SHA-256, SHA-384, and SHA-512 explicitly as examples. Also had to update the reference to the SHA document from NIST 180-2 (which did not contain SHA-2) to the current NIST 180-4 (which does)

Discussion:
All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. <del> The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske and cert_verify) is 20.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 FIPS.180-2, SHOULD be used instead. </del> <ins> A secure hash function such as SHA-256, SHA-384, or SHA-512 from FIPS.180-4 MUST be used. </ins> All EdDSA computations MUST be performed according to RFC8032 or its succesors.  Data to be signed/verified is run through the EdDSA
Change:
RFC 7748, TLS 1.3, and existing implementations do not check the significant bit. Instead, they mask it off. Align with all of these. Also tweak the all-zeros citation. RFC 7748 describes it as an optional check.
This looks goo to me.
LGTM

Discussion:
point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). Let's define legitimate values of x as the values that can be obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). Since there are some implementation of the X25519 function that impose this restriction on their input and others that don't, implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the final byte is set (in other words, when the value of the rightmost byte is greater than 0x7F) in order to prevent implementation fingerprinting.  Note that this deviates from RFC 7748 which suggests that This value be masked. </del> <ins> With X25519 and X448, a receiving party MUST check whether the computed premaster secret is the all-zero value and abort the handshake if so, as described in section 6 of RFC7748. </ins> Ed25519 and Ed448 internally do public key validation as part of signature verification. <del> Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with X25519. </del> 6. The table below defines new ECC cipher suites that use the key
Change:
I've restructured a little in support of this. I think that forward secrecy is more pertinent than the analogous finite-field stuff. I can make this less intrusive if you feel like the changes are gratuitous.

Discussion:
encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC. <del> The table below summarizes the new key exchange algorithms, which mimic DHE_DSS, DHE_RSA, and DH_anon, respectively. The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy.  With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve p references (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </del> <ins> tbl2 summarizes the new key exchange algorithms.  All of these key exchange algorithms provide forward secrecy. These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, respectively. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </ins> The anonymous key exchange algorithm does not provide authentication of the server or the client.  Like other anonymous TLS key exchanges,
Change:
Annex B.1 also contain some text regarding the rate. E.g. "The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media starts flowing." I guess we should discuss whether: 1) We need to remove/modify that text 2) Whether B.1 is the place where we should talk about the global rate limit.
I'll own this issue because I'm driving discussion on the list around the transport guys' proposal for "MaxPackets+HTO+pacing".
Hopefully fixed by URL

Discussion:
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. <del> ICE agents MUST NOT use a Ta value smaller than 5 ms. </del> If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE

values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. <ins> Regardless of the Ta value chosen for each ICE agent, the combination of all transactions from all ICE agents (if a given implementation runs several concurrent ICE agents) MUST NOT be sent more often than once every 5ms (as though there were one global Ta value for pacing all ICE agents). This mechanism of a global minimum pacing interval of 5ms is not generally applicable to transport protocols, but is applicable to ICE based on the following reasoning. Start with the following rules which would be generally applicable to transport protocols: Let MaxBytes be the maximum number of bytes allowed to be outstanding in the network at start-up, which SHOULD be 14600 bytes per RFC 6928. Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms otherwise.  This is based on the RTO for STUN messages from RFC 5389 and the the TCP initial RTO, which is 1 sec in RFC 6298. Let MinPacing be the minimum pacing interval between transactions, which SHOULD be 5ms. Observe that ICE agents typically do not know the RTT for ICE transactions (connectivity checks in particular), meaning that HTO will almost always be 500ms. Observe that a MinPacing of 5ms and HTO of 500ms gives at most 100 packets/HTO, which for a typical ICE check of less than 120 bytes means a maximum of 12000 outstanding bytes in the network, which is less than the maximum expressed by rule 1. Thus, for ICE, the rule set reduces down to just the MinPacing rule, which is equivalant to having a global Ta value. </ins> NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values.
Change:
Not sure this is correct. ICE session is something that continues until ufrag/passwords change. The same candidates can be re-used across multiple ICE sessions.
I think better definition will be: An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations and keep-alives) between the ICE agents until all the candidates are released or ICE-restart is initiated by ufrag/password change.
Roman's suggestion looks good.
I think the current proposed explanation (one with more details) is good. Would suggest merging this.
My suggestion is to merge, submit a new version, and then continue working on Peter's issues.
Why not just say an ICE session is all ICE activity tied to a candidate exchange with a specific ufrag/pwd? Every time you do a candidate exchange with a new ufrag/pwd, you have a new ICE session. I don't think we need to say all the rest.

Discussion:
This specification makes use of the following additional terminology: <ins> An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations and keep-alives) between the ICE agents until all the candidates are released or ICE-restart is triggered. </ins> An agent is the protocol implementation involved in the ICE candidate exchange.  There are two agents involved in a typical candidate exchange.
Change:
It looks like two references didn't get translated into xml2rfc xref tags when RFC 5245 got imported.
LGTM! Thanks!

Discussion:
address and port) in addition to the ICE parameters. STUN connectivity checks between agents are authenticated using the <del> short-term credential mechanism defined for STUN [RFC5389].  This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server.  The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon.  Each agent also provides a password, used to compute the message integrity for requests it receives.  The username fragment and password are exchanged between the peers.  In addition to providing security, the username provides disambiguation and correlation of checks to media streams.  See Appendix B.4 for motivation. </del> <ins> short-term credential mechanism defined for RFC5389.  This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server.  The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon.  Each agent also provides a password, used to compute the message integrity for requests it receives.  The username fragment and password are exchanged between the peers.  In addition to providing security, the username provides disambiguation and correlation of checks to media streams.  See sec-why-uname for motivation. </ins> If the initiating agent is a lite implementation, it MUST indicate this when sending its candidates .
Change:
From URL : JSON objects with a null "type" are syntactically correct, but there is no information on how it should be handled. { "type": null, "status": 404, "title": "Not Found" } It makes sense to treat null as an alias of "about:blank" and that's how I think it should be documented.
Note that the errata above is only . My .02 -- if is , it's invalid, not "syntactically correct"; it's specified to be a string, and if someone assumes that has semantics, that's not currently specified behaviour. So the real question here is whether the default of is assumed when the value is invalid, or whether some other error handling comes into play. I think the safest thing to do would not be to assume that implies -- i.e., no change to the spec.
Since this is a specification of a format for error messages, I believe it is important that the processing of the error message is clear and lenient so the processing itself does not cause errors, possibly shrouding the initial error that caused the response in the first place. I therefore think the specification should be explicit that all erroneous values (such as , , , etc.) should be ignored and treated as the default value of each member, which for equals to , but for other members equal to an empty string(?).
I think I agree; changing issue title.

Discussion:
3.1. <del> A problem details object can have the following members: </del> <ins> Problem detail objects can have the following members.  If the type of a member's value does not match the specified type, the member MUST be ignored - i.e., processing will continue as if the member had not been present. </ins> 3.1.1.
Change:
As discussed in URL, this PR expands on the dereferenceability of to clarify what the URI is expected to return, which hopefully also clarify the intended use of .
Merging, might tweak a bit further in situ. Thanks!

Discussion:
that identifies the specific occurrence of the problem.  It may or may not yield further information if dereferenced. <ins> When the "instance" URI is dereferenceable it can return the same problem response that was returned to the client which generated the problem originally.  It might also return more information about the problem occurrence in other formats (e.g., using proactive content negotiation; see HTTP, Section 12.5.1). When the "instance" URI is not dereferenceable, it serves as a unique identifier for the problem occurrence that may be of significance to the server, but is opaque to the client. </ins> When "instance" contains a relative URI, it is resolved relative to the document's base URI, as per RFC3986, Section 5.  However, using relative URIs can cause confusion, and they might not be handled
Change:
Currently: That doesn't seem like a recipe for good interop. While it doesn't need to be an RFC, some sort of reference is necessary...
I'm sorry, but I don't quite understand what is being referred to here. Is the quoted paragraph from RFC7807? Because I can't find it. Without more context I also don't quote understand what it is referring to.
NAME https://ietf-wg-URL

Discussion:
This specification defines the HTTP Problem Type registry for common, widely-used problem type URIs, to promote reuse. <del> A Designated Expert reviews and approves registration requests, as per RFC8126, Section 4.5.  A specification document is appreciated, but not required. </del> <ins> The policy for this registry is Specification Required, per RFC8126, Section 4.5. </ins> When evaluating requests, the Expert(s) should consider community feedback, how well-defined the problem type is, and this specification's requirements.  Vendor-specific, application-specific, <del> and deployment-specific values are not registrable. </del> <ins> and deployment-specific values are not registrable.  Specification documents should be published in a stable, freely available manner (ideally located with a URL), but need not be standards. </ins> Registrations MAY use the prefix "https://iana.org/assignments/http- <del> problem-types#", and are encouraged to do so when a stable, neutral URI is desirable. </del> <ins> problem-types#" for the type URI. </ins> Registration requests should use the following template:
Change:
It seems that saying could be read as identifying the problem instance rather than identifying the problem type. Here's a minor edit to make this more explicit: It's not quite clear to me what other identifiers could be (patterns of extension members, maybe?), but that's a different question.

Discussion:
The "type" member is a JSON string containing a URI reference URI that identifies the problem type.  Consumers MUST use the "type" URI <del> (after resolution, if necessary) as the problem's primary identifier. </del> <ins> (after resolution, if necessary) as the problem type's primary identifier. </ins> When this member is not present, its value is assumed to be "about:blank".