jiebi/CodeConvo huggingface dataset:
Code change:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Related discussion:
text: Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the working <del> group. A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf- <wgname>-wg. </del> <ins> group.  A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf-<wgname>-wg. </ins> A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much
Code change:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Related discussion:
text: to all repositories and ownership does not grant any other significant privileges. <del> When Area Directors or Working Group Chairs change, teams MUST be updated to reflect the new membership status. When a Working Group is closed, the responsible Area Director is responsible for removing existing members from teams in the organization.  Repositories MUST be updated along to indicate that they are no longer under development. </del> <ins> Details about creating organizations adhering to these guidelines can be found in GIT-CONFIG. </ins> 2.2. <del> When an IETF Working Group is closed or when associated mailing lists are closed, mail archives and datatracker information from that work is backed up and accessible.  The same applies to GitHub repositories. Any repositories including issues and discussion SHOULD be backed up on IETF resources.  It is desirable for those to be accessible via the Working Group's datatracker page.  For example, this might be via URLs listed in the More Info section on the Working Group Charter page. The IETF MAY decide to backup information associated with a Working Group's organization periodically.  This decision can be made differently per Working Group in consultation with the responsible Area Director. 2.3. </del> Each Working Group MAY set its own policy as to whether and how it uses GitHub.  It is important that occasional participants in the WG and others accustomed to IETF tools be able to determine this and
Code change:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Related discussion:
text: to those mailing lists should be given.  An example of this is at https://datatracker.ietf.org/wg/quic/charter/. <del> 2.3.1. One important policy is the IETF IPR policy (see RFC5378, RFC3979, and RFC4879).  Part of this policy requires making contributors aware of the policy. The IETF Trust license file for open source repositories [5] MUST be included prominently in any document repository. Including this information in the CONTRIBUTING file is sufficient. In addition to the boilerplate text there can be a benefit to including pointers to other working group materials, the IETF datatracker, specific drafts, or websites.  Adding such text is at the discretion of the Working Group Chairs. </del> 3. A Working Group Chairs are responsible for determining how to best
Code change:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Related discussion:
text: An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml <del> [6].  This tool has been used effectively in several working groups, </del> <ins> [5].  This tool has been used effectively in several working groups, </ins> though it requires server infrastructure. A working group that uses GitHub MAY provide either facility at the
Code change:
I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.

Related discussion:
text: [4] https://about.gitlab.com/ <del> [5] https://trustee.ietf.org/license-for-open-source- repositories.html [6] https://github.com/dontcallmedom/github-notify-ml </del> <ins> [5] https://github.com/dontcallmedom/github-notify-ml </ins>
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <del> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </del> 2.3. When the server can parse the client's first flight using the
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: 6. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  If the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, it is possible for some application layer protocols to not be able to run over some of the offered compatible versions.  It is the server's responsibility to only select an ALPN token that can run over the compatible QUIC version that it selects. A given ALPN token MUST NOT be used with a new QUIC version different from the version for which the ALPN token was originally defined, unless all the following requirements are met: The new QUIC version supports the transport features required by the application protocol. The new QUIC version supports ALPN. The version of QUIC for which the ALPN token was originally defined is compatible with the new QUIC version. When incompatible version negotiation is in use, the second connection which is created in response to the received version negotiation packet MUST restart its application layer protocol negotiation process without taking into account the original version. 7. </ins> In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it.
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1. <del> 6.1. </del> <ins> 7.1. </ins> QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: handshake even though the Retry itself was sent using the original version. <del> 6.2. </del> <ins> 7.2. </ins> QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. <del> 6.3. </del> <ins> 7.3. </ins> QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. <del> 7. </del> <ins> 8. </ins> Because QUIC version 1 was the only IETF Standards Track version of QUIC published before this document, it is handled specially as
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: version negotiation to negotiate versions other than QUIC version 1 will need to implement this draft. <del> 8. </del> <ins> 9. </ins> The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: possibility of cross-protocol attacks, but more analysis is still needed here. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> This document registers a new value in the "QUIC Transport Parameters" registry maintained at
Code change:
Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM

Related discussion:
text: of a codepoint in the 0-63 range to replace the provisional codepoint described above. <del> 9.2. </del> <ins> 10.2. </ins> This document registers a new value in the "QUIC Transport Error Codes" registry maintained at <<https://www.iana.org/assignments/
Code change:
I am not sure that I agree with this as some state carries across from the first connection attempt to the second (and hopefully successfully completed) connection. (Also, I've implemented this within the same connection object. I know that other implementations differ here, so what I'm looking for is a little finesse in how this is framed.)

Related discussion:
text: attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. <ins> Note that this separation across two connections is conceptual: it applies to normative requirements on QUIC connections, but does not require implementations to internally use two distinct connection objects. </ins> 2.5. When the client picks its original version, it will try to avoid
Code change:
Bijective should be symmetric. We're describing a relation not a function. This is a very minor comment, will send a PR hopefully soon.
Indeed, my math is pretty rusty :) Totally agree with you, and thanks for offering to write the PR!
NAME any luck with the PR?
I completely forgot about this!
URL opened
Closing now that has been merged.

Related discussion:
text: differ after the handshake, then A is compatible with B and B is compatible with A. <del> Version compatibility is not bijective: it is possible for version A </del> <ins> Version compatibility is not symmetric: it is possible for version A </ins> to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A.
Code change:
The draft says explicitly that receiving Version Negotiation terminates a connection attempt. This isn't consistent with that. This probably needs to say something like this instead:
That sounds good to me, can you make this a PR?

Related discussion:
text: 6. Clients MUST ignore any received Version Negotiation packets that <del> contain the version that they initially attempted.  Once a client has reacted to a Version Negotiation packet, it MUST drop all subsequent Version Negotiation packets on that connection. </del> <ins> contain the version that they initially attempted.  A client that makes a connection attempt based on information received from a Version Negotiation packet MUST ignore any Version Negotiation packets it receives in response to that connection attempt. </ins> Both endpoints MUST parse their peer's Version Information during the handshake.  If parsing the Version Information failed (for example,
Code change:
NAME suggested this. It's a simplification that should reduce errors. It prevents topics like "Hello world!", but that's probably a good thing on balance.

Related discussion:
text: topic is used to correlate push messages sent to the same subscription and does not convey any other semantics. <del> The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. </del> <ins> The grammar for the Topic header field uses the "token" rule defined in RFC7230. </ins> For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64
Code change:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Related discussion:
text: Generic Event Delivery Using HTTP Push <del> draft-thomson-webpush-protocol-latest </del> <ins> draft-ietf-webpush-protocol-latest </ins> Abstract
Code change:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Related discussion:
text: Examples in this document use the RFC7230.  Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 is necessary, the more <del> verbose frame format from I-D.ietf-httpbis-http2 is used. </del> <ins> verbose frame format from RFC7540 is used. </ins> 2.
Code change:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Related discussion:
text: A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource.  The push <del> service does not respond to this request, it instead uses I-D.ietf- httpbis-http2 to send the contents of push messages as they are sent by application servers. </del> <ins> service does not respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. </ins> Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created
Code change:
closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.

Related discussion:
text: The application server requests the delivery of receipts from the push server by making a HTTP GET request to the receipt subscription resource.  The push service does not respond to this request, it <del> instead uses I-D.ietf-httpbis-http2 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </del> <ins> instead uses RFC7540 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </ins> Each receipt is pushed in response to a synthesized GET request.  The GET request is made to the same push message resource that was