jiebi/CodeConvo huggingface dataset:
Code change:
draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.

Related discussion:
text: length of the digest output.  This codepoint is also defined for use with TLS 1.2. <del> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </del> <ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list
Code change:
draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.

Related discussion:
text: suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I- <del> D.sandj-tls-iana-registry-updates has been applied.]] </del> <ins> D.ietf-tls-iana-registry-updates has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.
Code change:
Need to be explicit say that it's the ExtensionType registry from RFC 4366.
I literally was making the same change in my editor when the notification came in! (Should it be the "TLS Extensions ExtensionType registry"?)

Related discussion:
text: "encrypted_extensions", "end_of_early_data", "key_update", and "handshake_hash" values. <del> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its allocation policy is listed below: </del> <ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document. The registry and its allocation policy is listed below: </ins> IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes",
Code change:
When we banned client auth and PSK, we only meant to do it for the main handshake, not the post-handshake phase. This reverts that change, as well as clarifies the prophibition on PSK plus cert-based auth.

Related discussion:
text: authorities). Servers which are authenticating with a PSK MUST NOT send the <del> CertificateRequest message. </del> <ins> CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). </ins> 4.3.2.1.
Code change:
Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.

Related discussion:
text: candidates, such as STUN and TURN. All of the candidates sent within an ICE session; these are the <del> candidates that are associated with a local/remote ufrag pair (which will change on ICE restart, if any). </del> <ins> candidates that are associated with a specific local/remote ufrag pair (which will change on ICE restart, if any occurs). </ins> Any session-related (as opposed to candidate-related) attributes required to configure an ICE agent.  These include but are not
Code change:
Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.

Related discussion:
text: Once the candidate has been sent to the remote party, the agent checks if any remote candidates are currently known for this same <del> stream.  If not, the new candidate will simply be added to the list of local candidates. </del> <ins> stream and component.  If not, the new candidate will simply be added to the list of local candidates. </ins> Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it will begin pairing the
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: The use of source control improves traceability and visibility of changes.  Issue tracking can be used to manage open issues and provide a record of their resolution.  Pull requests allow for better <del> engagement on technical and edditorial changes, and encourage </del> <ins> engagement on technical and editorial changes, and encourage </ins> contributions from a larger set of contributors.  Using GitHub can also broaden the community of contributors for a specification.
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: Working Groups might integrate the capabilities provided by GitHub into their processes for developing Internet-Drafts. <del> This document is meant as an supplement to existing Working Group </del> <ins> This document is meant as a supplement to existing Working Group </ins> practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established RFC 2418 RFC2418.  The small number of rules in this </del> <ins> established by RFC 2418 RFC2418.  The small number of rules in this </ins> document are there to ensure common usage patterns between working groups and to avoid issues that have been encountered in the past. A companion document, GH-CONFIG, describes administrative processes <del> that supports the practices described in this document. </del> <ins> that support the practices described in this document. </ins> 1.1.
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional features to GitHub.  For instance, BitBucket [4], or GitLab [5] <del> provide a similar feature set.  In additional to a hosted service, </del> <ins> provide a similar feature set.  In addition to a hosted service, </ins> software for custom installations exists. This document concentrates primarily on GitHub as it has a large and
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: 3. <del> A Working Group Chairs are responsible for determining how to best </del> <ins> Working Group Chairs are responsible for determining how to best </ins> accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if <del> a the proposed policy and use is acceptable. </del> <ins> the proposed policy and use is acceptable. </ins> <del> Chairs MUST involve Area Directors any decision to use GitHub for anything more than managing of drafts. </del> <ins> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </ins> While a document editor can still use GitHub independently for documents that they edit, even if the working group does not
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: multiple documents. Maintaining multiple documents in the same repository can add <del> overheads that negatively affect individual documents.  For instance, </del> <ins> overhead that negatively affects individual documents.  For instance, </ins> issues might require additional markings to identify the document that they affect.  Also, because editors all have write access to the repository, managing the set of people with write access to a larger
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: One common practice is to use these continuous integration services to build a text or HTML version of a document.  This is then published to GitHub Pages, which allows users to view a version of <del> the most recent revision of a document.  Including prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </del> <ins> the most recent revision of a document.  Including a prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </ins> Continuous integration can also validate pull requests and other changes for errors.  The most basic check is whether the source file <del> can be transformed successful into a valid Internet-Draft.  For </del> <ins> can be transformed successfully into a valid Internet-Draft.  For </ins> example, this might include checking that XML source is syntactically correct. <del> For documents that use formal languages a part of specifications, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </del> <ins> For a document that use formal languages as part of the specification, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </ins> 8.
Code change:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Related discussion:
text: If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what <del> venue the issue was raised in, email, issue discussion, a pull request review, capturing issues quickly ensures that problems become visible and can be tracked. </del> <ins> venue the issue was raised in (e.g., email, issue discussion, a pull request review); capturing issues quickly ensures that problems become visible and can be tracked. </ins> This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of
Code change:
Two changes, two issues, but really this is the one idea. The previous draft said that features not used could be disabled. This is bad advice because that might be denying editors access to tools that would make their task easier. The new advice says that editors can use features that the working group doesn't rely on. It also says that chairs should consult editors to ensure that policies aren't adversely affecting them.
Most of the operating modes assume that editors are given considerable latitude in how repositories are managed. This is good up until the point that the Working Group starts to formally rely on things that are in the respository. The document sort of prevaricates about this point, including strong admonitions that suggest rules be formalized for every aspect of usage. Instead, I think that it would be better if the document said - up-front - that editors are to be given control unless the Working Group starts to formally depend on a particular function (like issue opening/closing, labels, pull requests, whatever...). At that point, it is the chair's responsibility to identify what the WG depends on and to clearly articulate the policies around that usage.
Section 3.1 talks about turning off GitHub features not being used by the WG, but it doesn't say how to do that in the UI. I ask this because I cannot see a way to prevent issues or PRs just by wandering through the GUI.
This isn't something that I'd want to publish. The way that features are configured is too tightly coupled to UX decisions that GitHub might remake and any point. In fact, I might prefer not to include the offending text at all. Disabling features can be a useful way to slim down the options presented to users (which can help new users), but it can also be fairly hostile to new contributors. For instance, if the working group disables issues because they aren't using them, it sounds reasonable, but new contributors might then be dissuaded from opening a genuine issue. Working groups might be better served by informally letting contributors know how to best provide their input.
I'm happy with either the current text plus "At the time this is written, to turn of y" or removing the suggestion.

Related discussion:
text: Group will rely upon.  features contains a more thorough discussion on the different features that can be used. <del> Once a document is published in a repository on GitHub, many features like pull requests, issue tracking or the wiki can be individually disabled.  If specific features are not used by the Working Group in the development of the document, disabling those features avoids creating confusion in the wider community about what can be used. </del> 3.2. Working Group Chairs that decide to use GitHub MUST inform their
Code change:
This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)

Related discussion:
text: sufficient, though it might be helpful to occasionally remind new contributors of these guidelines. <del> A choice to use GitHub is similar to the formation of a design team (see Section 6.5 of RFC2418) provided that the work uses a public repository.  That is, the output of any activity using GitHub needs to be taken to the Working Group mailing list and subject to approval, rejection, or modification by the Working Group as with any other input. </del> Working Group Chairs are responsible for ensuring that any policy they adopt is enforced and maintained.
Code change:
This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)

Related discussion:
text: documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. <ins> Work done in GitHub has no special status.  The output of any activity using GitHub needs to be taken to the Working Group and is subject to approval, rejection, or modification by the Working Group as with any other input. </ins> 3.2. New repositories can be created within the Working Group organization
Code change:
We should review the appendices and include the appropriate references to them through the main body of the document.

Related discussion:
text: discovered.  Such elements may include classes of data, major roles, and role interactions.  This scenario also informs protocol and data model development in support of vulnerability assessment, as part of <del> overall posture assessment.  Vulnerability discovery, disclosure, and publication is out of scope. </del> <ins> overall posture assessment (see implementation-examples for examples of solutions that support this scenario). Vulnerability discovery, disclosure, publication, and prioritization is out of scope.  However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in priority. Information on how the scenario aligns with SACM and other existing work is discussed in sacm-usage-scenarios through alignment-with- other-existing-works. </ins> 2.
Code change:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Related discussion:
text: Push services might need to limit the size and number of stored push messages to avoid overloading.  In addition to using the 413 (Payload Too Large) status code for too large push messages, a push service <del> MAY expire push messages prior to any advertised expiration time. </del> <ins> MAY expire push messages prior to any advertised expiration time.  A push service can reduce the impact push message retention by reducing the time-to-live of push messages. </ins> 7.3.
Code change:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Related discussion:
text: 9. <ins> This protocol defines new HTTP header fields in iana.header.fields. New link relation types are identified using the URNs defined in iana.urns. 9.1. HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- headers/>. This document defines the following HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see RFC3864): The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 9.2. </ins> This document registers three URNs for use in identifying link relation types.  These are added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of RFC3553; the
Code change:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Related discussion:
text: (this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:reg