jiebi/CodeConvo huggingface dataset:
Change:
request is a stub registration object containing only the "contact" field. <del> The server MUST ignore any values provided in the "key", "authorizations", and "certificates" fields in registration bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. </del> <ins> The server MUST ignore any values provided in the "key", and "applications" fields in registration bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. </ins> The server creates a registration object with the included contact information.  The "key" element of the registration is set to the

Discussion:
In the "applications" field of the registration resource is described in great detail. This is confusing for two reasons: both the text and the example registration object are still using the "authorization" term that applications replace. the text is written as if the applications should be directly embedded in the registration object returned. This PR addresses both issues by describing the "applications" field as an array of application URIs that the client can fetch. The example "registration" object is updated accordingly. The note indicating a server SHOULD include pending applications and SHOULD NOT include invalid applications remains as-is. The note indicating a server MAY return an incomplete list is removed - it is more complicated and with only URIs being returned, likely an unneeded optimization. Finally, in there are three fields that must be ignored by the server in a registration body: key, authorizations and certificates. This should be "key" and "applications" and is updated accordingly.
NAME feedback addressed, and conflicts w/ master resolved. Thanks for the :eyes: !
Change:
empty nodelist is a valid query result. A segment performs its function on each of the nodes in its input <del> nodelist.  During such a function execution, each such node is referred to as the "current node".  Each of these function executions produces a nodelist, which are then concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </del> <ins> nodelist.  Each of these function executions produces a nodelist, which are then concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </ins> A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered

Discussion:
Fixes URL
I left that in deliberately. We have removed the colliding term and we are now free to use current node () throughout. I will follow up with a PR which does just that. I objected to the term "function" in this context previously. I'll follow up with a PR to delete it, which will leave it free for function extensions.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL
Note that there is still an instance of "current node identifier" in table 1. I also note that then English usage of "function" now collides with the term we coin in the function extensions. But the basic change here is right, so I approve.
Change:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. </del> <ins> inclusive.  In a fully-qualified domain name, the first label (logically speaking) is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. </ins> Format of names -- Names in the global DNS are domain names. There are three formats: wire format, presentation format, and

Discussion:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.
Change:
identities.  Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS-PSK. <del> 6.3. </del> <ins> 6. Applications MUST use external PSKs that adhere to the following requirements: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a server MUST use distinct PSKs when acting as the client from when it is acting as the server. Nodes SHOULD use external PSK importers I-D.ietf-tls-external-psk- importer when configuring PSKs for a pair of TLS client and server. Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated.  This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself. 6.1. </ins> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for

Discussion:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!
Change:
7. IANA is requested to allocate an entry to the TLS "ContentType" <del> registry, for the return_routability_check(TBD) defined in this document. IANA is requested to allocate an entry to the TLS Flags registry in the tls_flags type: Value: [[IANA please assign a value from the 32-63 value range.]] Flag Name: RRC Message: CH,SH Recommended: Y </del> <ins> registry, for the "return_routability_check(TBD2)" defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. </ins> <del> Reference: [[This document]] </del> <ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. </ins> 8.

Discussion:
Use a new extension type instead.
Yes, if tls-flags are not usable for DTLS 1.2, then go with this.
We'd like to use to negotiate RRC. At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear. For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case. Achim has opened an . This issue is for tracking on the RRC side.
Change:
If the update was not successful, then the server responds with an error status code and a problem document describing the error. <del> 6.5. </del> <ins> 6.3.2. </ins> Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The

Discussion:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).
Change:
a Certificate message containing no CertificateEntries and the CertificateVerify message omitted.  The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key.  This <del> message does not include any TLS framing. </del> <ins> message is encoded as a TLS handshake message, including length and type field.  It does not include TLS record layer framing. </ins> 7.

Discussion:
Proposal to fix Issue
cc NAME
The Introduction limits this to TLS 1.2 and later, but DTLS is similar. Do you want to take that into account now, or ignore it? DTLS has additional fields to support fragmentation: URL URL
Exported authentication are meant to be embedded in a higher-layer protocol, so there's no need to support fragmentation.
The draft states that there should be no "TLS framing" but what is meant is that the handshake messages shouldn't be encapsulated by TLS Record Framing (which does the encryption of the handshake messages).
Change:
"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), <del> sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del> <ins> sha1, sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> [[TODO: IANA considerations for new SignatureAlgorithm value]]

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.
Change:
signature_algorithms) It returns an authenticator request, which is a sequence of octets <del> that comprises a CertificateRequest message. </del> <ins> that comprises a CertificateRequest or ClientCertificateRequest message. </ins> 7.2.

Discussion:
A reference QUIC would also need to be added to the references section If it's an informative draft maybe not a thing, but if it's a normative reference then this draft will sit in the queue until QUIC transport gets published. Maybe that's okay, but just an FYI.
I may be missing some follow-on discussions, but: Ben suggested that we mention that QUIC is also an option, even if informatively, in addition to the “SHOULD use TLS” statement. I think we left my question re: back-fitting this protocol into the IANA TLS registry open. Quoting: YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allowing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. NS: This is a good point and one that we struggled a bit with during design. We needed to allow SNI in the CertificateRequest message because it can be client-generated in this context. I'd be ok with creating a different extension for this, but it's rather elegant to re-use it in this context. I'd like to hear some opinions from the working group on this point BK: Or, since extension codepoints are cheap, just use a new codepoint.
Addressed by .
Change:
When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero <del> vector of length Hash.length. </del> <ins> vector of length Hash.length, where the Hash algorithm is defined by the ciphersuite. </ins> 5.8.

Discussion:
Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks
Change:
generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. <del> 6.3. </del> <ins> 7.3. </ins> A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
Either or both confidentiality and integrity at the data layer. <ins> 4.2. SACM information may contain sensitive information about the target endpoint as well as revealing identity information of the producer or consumer of such information.  Similarly, as part of the SACM discovery mechanism, the advertised capabilities (and roles, e.g. SACM components enabled) by the endpoint may be construed as private information.  There may be applications as well as business and regulatory practicess that require that aspects of such information be hidden from any parties that do not need to know it. Data confidentiality can provide some level of privacy but may fall short where unecessary data is still transmitted.  In those cases, filtering requirements at the data model such as OP-005 must be applied to ensure that such data is not disclosed.  RFC6973 provides guidelines for which SACM protocols and information and data models should follow. </ins> 5. 5.1.

Discussion:
Updates to address 3 of four open issues
Version -09 The document is not consistent if the character following the pithy title is capitalized. A pass needs to be made to fix this.
Hi Jim, I only found 1 straggler in IM-URL there are others please let me know so I can fold it into the -10 draft. Thanks, Nancy
Fixed in Pull request
-version 09 There are two nits that needs to be resolved. Missing 2119 boilerplate Reference to RFC 3444 exists, but is not referred to.
Hi Jim, Will fix in -10 draft..... Thanks, Nancy
Fixed in Pull request
Change:
ECN codepoints to affect the sender's rate.  If duplicate packets are discarded by a receiver, an off-path attacker will need to race the duplicate packet against the original to be successful in this <del> attack.  Therefore, QUIC receivers ignore ECN codepoints set in duplicate packets (see ecn). </del> <ins> attack.  Therefore, QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn. </ins> 21.8.

Discussion:
NAME made a good suggestion in , which I have taken and tweaked further. It is not sufficient to discard ECN if one QUIC packet is discared, you need to discard ALL QUIC packets in the IP packet.
Sounds about right to me.
S 21.7 This could use more elaboration. As written, it seems like if you win the race (which you might like half the time) then you will succeed in the attack. Is that true?
Yes, the winner of a race can reduce the congestion window or maybe prevent it from being reduced.
As I see this: QUIC receivers ignore the ECN codepoint field received in IP packets that carry duplicate QUIC packets (see {{ecn}}).
So NAME is this resolved or do you expect more than what Martin wrote?
I think that I can make that call now. If there is a problem, we can open an issue.
Change:
3.5.5.1. <del> The filter selector has the form "?<expr>".  It works via iterating over structured values, i.e. arrays and objects. </del> <ins> The filter selector has the form "?<expr>".  It iterates over structured values, i.e., arrays and objects. </ins> <del> During the iteration process each array element or object member is visited and its value -- accessible via symbol "@" -- or one of its descendants -- uniquely defined by a relative path -- is tested against a boolean expression "boolean-expr". The current item is selected if and only if the boolean expression yields true. </del> <ins> During the iteration process the node of each array element or object member being visited is known as the current node.  A boolean expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true. </ins> Paths in filter expressions are Singular Paths, each of which selects at most one node. <ins> The current node is accessible via the current node identifier "@". </ins> Parentheses MAY be used within "boolean-expr" for grouping. Comparisons are restricted to Singular Path values and primitive

Discussion:
There may be some more shake-out as filter semantics are scattered through the syntax section. We may need to live with this because it makes more sense to talk about semantics in the context of each particular piece of syntax. But let's use the current PR just to use the current node term consistently.
Change:
compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher. The two paragraphs below replaces the corresponding paragraphs in <del> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of RFC5216 still apply with the </del> <ins> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3.  The other paragraphs in Section 2.1.3 of RFC5216 still apply with the </ins> exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
parameter or constructed implicitly from the requester's network address. <del> Documents in RFC6690 Link Format SHOULD NOT contain links in which resolving the target literal against the base URI gives a different result than resolving it against the resolved anchor; this is to avoid the ambiguities described in resolution-rules. Entries in which there is no anchor attribute, entries in which the target is an absolute reference and entries in which both the target and the anchor start with a slash ("/") </del> <ins> Link format documents submitted to the resource directory are interpreted as Modernized Link Format (see modern6690) by the RD.  A registree-ep SHOULD NOT submit documents those interpretation according to RFC6690 and modern6690 differs and RFC6690 interpretation is intended to avoid the ambiguities described in resolution-rules. </ins> <del> never cause that kind of ambiguity. </del> <ins> In practice, most links (precisely listed in modern-safe) can be submitted without consideration for those details. </ins> The registration request interface is specified as follows:

Discussion:
This responds to a comment from Jim on the use of the term "Origin" in RFC6690 which I had previously missed. Given that the old 6690-style documents are thus a lot less powerful, the text goes from "Submitted documents should be the same in both interpretations, and the RD can use either" to "Submitted documents should be the same, and the RD interprets them 8288 style". A paragraph was added that defines precisely what it means to interpret it 8288 style. Several outdated references to where resolution happens have been removed. The "8288 style interpretation" is called Modernized Link Format; I'd be happy of any better names, but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again.
Change:
This event indicates which data was marked for retransmit upon detecting a packet loss (see packet_lost).  Similar to our reasoning for the "frames_processed" event, in order to keep the amount of <del> different events low, we group this signal for all types of retransmittable data in a single event based on existing QUIC frame definitions. </del> <ins> different events low, this signal is grouped into in a single event based on existing QUIC frame definitions for all types of retransmittable data. </ins> Implementations retransmitting full packets or frames directly can just log the constituent frames of the lost packet here (or do away

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that