jiebi/CodeConvo huggingface dataset:
Change:
7.1. <del> The following enhancement extends the voucher-request as defined in RFC8995 to include additional fields necessary for handling bootstrapping in the pledge-responder-mode. 7.1.1. The following tree diagram is mostly a duplicate of the contents of RFC8995, with the addition of the fields agent-signed-data, registrar-proximity-certificate, and agent-signing certificate.  The tree diagram is described in RFC8340.  Each node in the diagram is fully described by the YANG module in Section voucher-request-prm- yang-module. 7.1.2. The following YANG module extends the RFC8995 Voucher Request to include a signed artifact from the registrar-agent (agent-signed- data) as well as the registrar-proximity-certificate and the agent- signing certificate. </del> <ins> RFC8366bis extends the voucher-request as defined in RFC8995 to include additional fields necessary for handling bootstrapping in the pledge-responder-mode.  They are: agent-signed-data, registrar- proximity-certificate, and agent-signing certificate. </ins> Examples for the PVR are provided in exchanges_uc2_2.

Discussion:
move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.
Change:
ACME can also be used to automate some aspects of certificate management even where non-automated processes are still needed.  For example, the external account binding feature (see external-account- <del> binding) can be used to associate authorizations with an account that were not validated through the ACME authorization process.  This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of Extended Validation certificates. </del> <ins> binding) can allow an ACME account to use authorizations that have been granted to an external, non-ACME account.  This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of Extended Validation certificates. </ins> 2.

Discussion:
Merging because editorial.
account binding feature (see {{external-account-binding}}) can be used to associate authorizations with an account that were not validated through the ACME authorization process. To me (non-native English speaker) "were not" refers to "an account" which would be a grammar mistake. If it refers to "authorizations" would it be better to switch "authorizations" and "an account"?
I think it is technically correct (it does refer to "authorizations"), but I agree it's an awkward sentence. Filed to address.
Change:
8.3. <del> Following the guidelines defined in RFC5226, this document defines a </del> <ins> Following the guidelines defined in RFC8126, this document defines a </ins> new registry called "Capabilities for HTTPS Notification Receivers". This registry defines capabilities that can be supported by HTTPS- based notification receivers.

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. <del> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: ACM : Adaptive Coding and Modulation; BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; CPE: Customer Premises Equipment; COM: COMmunication; DSL: Digital Subscriber Line; DTN: Delay/Disruption Tolerant Network; DVB: Digital Video Broadcasting; E2E: End-to-end; ETSI: European Telecommunications Standards Institute; FEC: Forward Error Correction; FLUTE: File Delivery over Unidirectional Transport; IntraF: Intra-Flow Coding; InterF: Inter-Flow Coding; IoT: Internet of Things; LTE: Long Term Evolution; MPC: Multi-Path Coding; NC: Network Coding; NFV: Network Function Virtualization; NORM: NACK-Oriented Reliable Multicast; PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for satellite communications include compression, caching and TCP acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional information (e.g., related to synchronization); QEF: Quasi-Error-Free; QoE: Quality-of-Experience; QoS: Quality-of-Service; SAT: SATellite; SATCOM: generic term related to all kind of SATellite COMmunication systems; SPC: Single-Path Coding; VNF: Virtual Network Function. This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </del> 2. This section describes a satellite system that follows the ETSI DVB

Discussion:
Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?
In PR : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.
Change:
Example: Assuming the use of SHA-256 the extract phase of HKDF produces PRK_2e as follows: <del> where salt = 0x (zero-length byte string). </del> 4.1.1.2. The pseudorandom key PRK_3e2m is derived as follows:

Discussion:
Not sure this change is practically needed, but it is a simple change does not hurt. Actually simplifies the specification as the discussion on HKDF and empty string can be deleted.
No disagreement recorded - merging now.
The nonce used for the computation of PRK2e in the key schedule is set to be an empty. By replacing this empty string by the sid of the session, this makes the key PRK2e linked to the session connection identifiers and divides the chances for an attacker to correctly compute the key PRK_2e by the number of running sessions. More precisely, considering running sessions, computing Extract("",Z) with a random Z, the attacker may have a match with any of the sessions. While considering using a sid, computing Extract(sid, Z), the attacker may have a match only with the session using this sid.
This would increase the reduction bounds for PRK2e, but would it make a change if we consider the actual keystream? (and latter keys) As the transcript is included inside the derivation, the keystream2 does depend on all the information exchanged that could be used to build an sid. At a high level, the question is kind of the following I guess: is it better to do vs ? (I have no clue about the answer, but I would guess that if we rely on the PRF assumption, it is mostly the same?)
Making the following change would be relatively easy: But as charlie-j points out, TH2 is already included in all the Expand() derivations, so I am not sure that adding TH2 improves the practical security. For the inclusion of SID to make this "attack" harder the size of the curve would have to be smaller than the size of the hash function output. For the X25519-SHA-256 combination that is true but the size of X25519 is still 2^252. Brute forcing that would be much harder than brute forcing the typically 128 bit OSCORE key or breaking X25519 with Pollard's rho.
For comparison, below is how the TLS 1.3 key schedule looks like without PSK
This is not really true for the current: But would be true for
If we interpret in this quote as covering the PRKs, it is not true for any of them apart from PRKout, as similarly TH3 and TH4 are included only in K3 and K_4.

Good point. Let's see if we should reformulate "and all symmetric keys are derived using as much previous information as possible" is some way
The keys (and actually random material) that do follow this specification are the one form the key derivation figure: So an option would be to simply point at the figure?
Making a PR for this I noticed that this change has the benefit of allowing the text talking about HKDF and using the empty string as salt. Irrespectively of if the extra security factor is needed or not I therefore think this change should be done. There does not seem to be any negative affects of the change (except that it affects the test vectors).
PR is included in -16
Change:
concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and implementation documents.  The Preconnection allows applications <del> to configure Connection Properties, and the Connection represents an object that can be used to send and receive Messages. </del> <ins> to configure Connection Properties. </ins> <del> A Connection is an abstraction that represents the communication. If the transport services interface selects a protocol such as TCP for the communication, a Connection will correspond to an underlying protocol connection.  If however a protocol such as UDP is selected, the Connection remains an abstraction at the end points. </del> <ins> concepts also presents how an abstract Connection is used to select a transport protocol instance such as TCP, UDP, or another transport.  The Connection represents an object that can be used to send and receive Messages. </ins> 1.3.

Discussion:
Trying to with a hint upfront that connections can be UDP, TCP or any other transport protocol instance... and then later explain about a connection that can remain an abstraction at the end points for a UDP example.
The last bullet in the Overview is out of place - the others are an overview of the document, but this one is a description of a concept.
Change:
If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel(ation) item value of <del> "supplements" and an href item specifying an association with the </del> <ins> "supplemental" and an href item specifying an association with the </ins> software that is supplemented. If all of the corpus, patch, and supplemental items are "false",

Discussion:
Fixed typo identified by Alex Nelson. Also removed some extra working text that was accidentally left in an IANA section. This PR will be kept open until the WGLC concludes.
Change:
Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <del> FEC (also called Application-Level FEC) operate above the network layer. </del> <ins> FEC (also called Application-Level FEC) operate in and above the network layer. </ins> This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding

Discussion:
Q (Dave Oran): in or above network layer (above means no re-encoding in the router)? A: both - and the document is clear about it - no layer 2 coding. Q (Stew Card): what are the "C" is the architecture picture? A: this is where we could put the coding.
Done with PR and
Change:
them.  In particular, aggregators must store a batch as long as the batch has not been queried more than "max_batch_lifetime" times. However, it is not always necessary to store the reports themselves. <del> For schemes like Prio3 VDAF in which the input-validation protocol is only run once per report, each aggregator only needs to store its aggregate share for each possible batch interval, along with the number of times the aggregate share was used in a batch.  This is due to the requirement that the batch interval respect the boundaries defined by the DAP parameters.  (See batch-validation.) </del> <ins> For schemes like Prio3 VDAF in which reports are verified only once, each aggregator only needs to store its aggregate share for each possible batch interval, along with the number of times the aggregate share was used in a batch.  This is due to the requirement that the batch interval respect the boundaries defined by the DAP parameters. (See batch-validation.) However, Aggregators are also required to implement several per- report checks that require retaining a number of data artificts.  For example, to detect replay attacks, it is necessary for each Aggregator to retain the set of nonces of reports that have been aggregated for the task so far.  Depending on the task lifetime and report upload rate, this can result in high storage costs.  To elliviate this burden, DAP allows Aggregators to drop this state as needed, so long as reports are droppped properly as described in early-input-share-validation.  Aggregators SHOULD take steps to mitigate the risk of dropping reports (e.g., by evicting the oldest data first). </ins> Furthermore, the aggregators must store data related to a task as long as the current time has not passed this task's

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
)-1]. <del> Strings on the right-hand side of the "=~" regex matching operator MUST conform to I-D.draft-ietf-jsonpath-iregexp. </del> The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further errors relating to the well-formedness and the validity of a JSONPath

Discussion:
Weirdly, I cannot reply to this observation: URL Expiry is somewhat unusual for IANA registries (early allocations do expire). What is the behavior you would expect implementations to exhibit? The function extension to stop working on the expiry day?
Hey NAME based on this useful-looking discussion, do you plan to revise this significantly? I'm wondering if I should give it a careful read now or wait for an updated version.
Definitely. Of course, I'd like to have your input on the points raised (the non-trivial ones). We might even want to have a design-team meeting...
Might be a good idea to mark the non-non-trivial issues above resolved, to help reviewer focus. If it's OK, I'll wait for the next revision to go end-to-end. Agreed on a design meeting.
Here's my list of items where we could use input: More frugal with allowing whitespace? return value of functions that don't get the right arguments (e.g., length(1)) (interaction with -- non-singular paths in exist-expr) IANA designated expert instructions (frugal with "good" names) expiring reservations? (shades of certificates) domain of length (arrays now, add strings, objects?)? should there be another function for the size of nodelists (size())? Probably mostly resolved: for function names (ASCII, lowercase, only)
NAME I rebased this and resolved some conflicts.
Update: Address whitespace in a separate PR, if desired. Semantic issue: What to do with value of wrong kind? Fixed in 08dd7ad Fixed in afda44a Probably not. Semantic issue: What to do with value of wrong kind? Yes, that is called count() now (e3a565a) Let's stick with that name space.
We may be able to make this syntactically invalid. See URL for some ideas.
Change:
the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for <del> any operations.  TLS version 1.3 RFC8446 follows the same practice of specifying the psk identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1>). </del> <ins> any operation.  TLS version 1.3 RFC8446 follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1> in the specification).  RFC8446 also requires that the PSK identities are at least 1 byte and at the most 65535 bytes in length.  Although RFC8446 does not place strict requirements on the format of PSK identities, we do however note that the format of PSK identities can vary depending on the deployment: </ins> <del> Other assumptions unique to different stacks are listed below. </del> <ins> The PSK identity MAY be a user configured string when used in protocols like Extensible Authentication Protocol (EAP) RFC3748. gnuTLS for example treats PSK identities as usernames. </ins> <del> gnuTLS treats psk identities as usernames. </del> <ins> PSK identities MAY have a domain name suffix for roaming and federation. Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. identity-collision discusses some implication of collisions between external and resumption PSKs. 6.1.1.1. </ins> 7. <ins> It is NOT RECOMMENDED to share the same PSK between more than one client and server.  However, as discussed in use-cases, there are application scenarios that may rely on sharing the same PSK among multiple nodes.  I-D.ietf-tls-external-psk-importer helps in mitigating rerouting and selfie style reflection attacks when the PSK is shared among multiple nodes.  This is achieved by correctly using the node identifiers in the ImportedIdentity.context construct specified in I-D.ietf-tls-external-psk-importer.  It is RECOMMENDED that each endpoint selects one globally unique identifier and uses it in all PSK handshakes.  The unique identifier can, for example, be one of its MAC addresses, a 32-byte random number, or its Universally Unique IDentifier (UUID) RFC4122.  Each endpoint SHOULD know the identifier of the other endpoint with which its wants to connect and SHOULD compare it with the other endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other. 8. </ins> This document makes no IANA requests.

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:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-10 </del> <ins> draft-ietf-rtcweb-transports-11 </ins> Abstract

Discussion:
Updated terminology.
On reading the document, I find that the term "media flow" is used where draft-ietf-avtext-rtp-grouping-taxonomy suggests "source stream". Still open what to use instead of "data flow". "Data stream"?
After reconsidering, I added a definition for "flow" instead. Let's see how that scans.
rtcweb-transport: "normal", "below normal", "high" or "very high". tsvwg-rtcweb-qos: “very low”, “low”, “medium”, “high”. WEBRTC-PC: enum RTCPriorityType { "very-low", "low", "medium", "high" }; The majority should win.
Change:
4.1. This section describes a possible workflow when User Equipment <del> initially joins a Captive Network. </del> <ins> initially joins a Captive Portal. </ins> 4.2.

Discussion:
A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal aligns more closely with familiar use of the term. Further, other documents such as the API draft refer to the system as a whole as a Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash writes: I think that this is clear: one is a network and the other a server. Review to see if the right choice is used throughout. URL point out that we assume a degree of mutual control over both.
Change:
5. <del> TODO </del> <ins> The TLS external PSK authentication makes the implicit assumption that each PSK is known only to one client and one server, which do not switch roles with the same PSK. As discussed in use-cases, there are use cases where multiple clients or multiple servers share a PSK.  In such cases, TLS only authenticates the entire group.  Not only can a compromised group member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  This rerouting is a type of identity misbinding attack Sethi. Selfie attack Selfie is a special case of the rerouting attack against a group member that can act both as TLS server and client. In the selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint. </ins> 6.

Discussion:
Moved links in use cases sections to references and made the text somewhat more concise. Added some initial text on known attacks.
Change:
Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. <ins> Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate flows. </ins> 5.2. The traffic treatment required for a particular DetNet IP flow is

Discussion:
Note added to 5.1, that L4 multipath is out-of-scope. Please, check note and its placement that it is appropriate. URL URL Internet-Draft draft-ietf-detnet-ip-oam-URL is now available. It is a work item of the Deterministic Networking (DETNET) WG of the IETF. Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Authors: Greg Mirsky Mach(Guoyi) Chen David Black Name: draft-ietf-detnet-ip-oam-URL Pages: 9 Dates: 2024-02-05 Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTML version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
Hi Bernard, thank you for your thoughtful comments and helpful suggestions. The authors discussed them and updated the draft to address your concerns. I uploaded the new version: A new version of Internet-Draft draft-ietf-detnet-ip-oam-URL has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-detnet-ip-oam Revision: 11 Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Date: 2024-02-05 Group: detnet Pages: 9 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. Please let us know whether these updates adequately address your comments. Our sincere thanks for your help in improving this document. Regards, Greg (on behalf of the authors)