jiebi/CodeConvo huggingface dataset:
Change:
Media Distributor.  The Media Distributor decrypts and checks integrity of the hop-by-hop security.  The Media Distributor MAY change some of the RTP header information that would impact the end- <del> to-end integrity.  The original value of any RTP header field that is changed is included in a new RTP header extension called the Original Header Block.  The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent.  The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. </del> <ins> to-end integrity.  In that case, the original value of any RTP header field that is changed is included in a new RTP header extension called the Original Header Block.  The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent.  The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. </ins> One can think of the double as a normal SRTP transform for encrypting the RTP in a way where things that only know half of the key, can <del> decrypt and modify part of the RTP packet but not other parts of if </del> <ins> decrypt and modify part of the RTP packet but not other parts, </ins> including the media payload. 2.

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. <del> 6. </del> <ins> 7. </ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their prioritization preferences. <del> 7. </del> <ins> 8. </ins> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2.

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks
Change:
application using (D)TLS or externally configured on both sides, implementations MUST use the first method. <del> The server then iterates over all candidate ECHConfigs, attempting to decrypt the "encrypted_client_hello" extension: </del> <ins> The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension: </ins> The server verifies that the ECHConfig supports the cipher suite indicated by the ClientECH.cipher_suite and that the version of ECH

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
Abstract <del> The Transport Services architecture I-D.ietf-taps-arch defines a system that allows applications to use transport networking protocols flexibly.  This document serves as a guide to implementation on how to build such a system. </del> <ins> The Transport Services (TAPS) system enables applications to use transport protocols flexibly for network communication and defines a protocol-independent TAPS Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementation on how to build such a system. </ins> 1.

Discussion:
You cannot have references in the abstract. Initially I only wanted to remove that reference but then I also took the opportunity to rewrite the abstract a bit to not only talk about the architecture but an TAPS system and the interface that this guide helps with its implementation.
LGTM (I fixed a tiny nit directly with a commit)Thanks looks good.
Change:
identifiers.  This is to improve the interoperability of already consolidated practices, such as the one of writing OAS in YAML. <del> ex-fragid provides a non exhaustive list of examples that could help understanding interoperability issues related to fragment identifiers. </del> <ins> ex-fragid provides a non-exhaustive list of examples that could help understand interoperability issues related to fragment identifiers. </ins> 4.

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
6. <ins> RRC is not designed to counter on-path attackers.  These can never be distinguished from, for example, a genuine network device.  However, RRC can withstand off-path attackers of the type described below when the enhanced path validation algorithm (enhanced) is used. 6.1. </ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path

Discussion:
Section 5 title "Off-path packet forwarding" should be "Attack model" instead? Also, is this the right position? ISTM this should go after we discuss the base challenge/response mechanics. There is also a missing premise, I think: "RRC is not designed to counter on-path attackers. These can never be distinguished from, for example, a genuine network device. However, RRC can resist off-path attackers when enhanced path validation ({{enhanced}}) is used."
Change:
the one hand, the requirements on info seem weaker, but maybe actually this needs to be secret?  Analysis needed.]] <ins> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified integration with the backend server.  Stateless HRR on the client- facing server works fine, however.  See issue #333.]] </ins> 6.4. If the client attempts to connect to a server and does not have an

Discussion:
Issue .
I was thinking about and the discussion on server HRR checks started by URL, and I'm not sure HRR cookies even work in split mode right now. First off, suppose we don't merge something like . The current text says: This means if you get a cookied HRR only good for ClientHelloInner, there's no requirement to stick the cookie in ClientHelloOuter! But now the client-facing server can't see the cookie, so it can't be stateless. It would seem like fixes this, but now we have a more fundamental problem: whose cookie? Suppose the client-facing server wishes to handle HRR statelessly. It decrypts the first ClientHelloInner and forwards it to the backend server. If the backend server responds with HRR, the client-facing server must forward the HRR as-is, or the transcript breaks. But the client-facing server has no opportunity to bind its state (echhrrkey) into the HRR cookie. (Perhaps there isn't even one. If there is, it's encrypted with the backend server's key anyway. Either way, it's fixed now.) The simplest solution to all this is to only support stateful client-facing servers in split mode, unless the client-facing and backend servers can coordinate enough to share one cookie. I don't know if that would satisfy everyone. I could imagine doing something horrific to URL, akin to what we did to URL, but that sounds really messy.
Let's mark this as an "OPEN ISSUE" in the draft.
Done. URL
Change:
The entries in iana-setting-table are registered by this document. <ins> For fomatting reasons, setting names can be abbreviated by removing the 'SETTING_' prefix. </ins> Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of

Discussion:
This PR covers questions asked during Auth48 which aren't pure copyediting, but seem to have a straightforward single-location fix. Individual commits, so it's easy to pull one out if someone disagrees.
In , the RFC Editor asks:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .
Change:
If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should <del> also inform the Protocol Instance of potentially new paths that </del> <ins> also inform the Protocol Instance about potentially new paths that </ins> become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key). <del> 8.2. </del> <ins> 7.2. </ins> An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
Clients should not be able to send messages to groups which appear to be from other Clients <ins> Clients should not be able to perform trivial denials of service </ins> 4. As the MLS protocol provides an important service to users, its

Discussion:
As per Jan MLS meetup, malicious insiders should be considered as a potential threat, though perhaps in a restricted set of scenarios. It is probably bad if a malicious group member can trivially DoS people, for example, as in naïve ART.
Change:
This method is indicated by "dpop" in the "proof" field.  The client instance creates a Demonstration of Proof-of-Possession signature <del> header as described in I-D.ietf-oauth-dpop section 2.  In addition to the required fields, the DPoP body MUST also contain a digest of the request body: </del> <ins> header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: </ins> Digest of the request body as the value of the Digest header <del> defined in RFC3230. </del> <ins> defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. When a request is bound to an access token, the access token hash value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash algorithm used in the "alg" header parameter of the JWS's JOSE Header.  For instance, if the "alg" is "RS256", hash the "access_token" value with SHA-256, then take the left-most 128 bits and base64url encode them. </ins> 7.3.5.

Discussion:
Changes field to , adds to DPoP definition for parity with other JOSE signature methods.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fc15fc873432dae90bce38706aa85313d831d419 https://deploy-preview-195--gnap-core-protocol-editors-URL
The signature methods all need to cover the access token, but the DPoP method currently does not. We can add the method used in the and methods.
The FAPI WG is proposing a similar DPoP profile: URL This uses the field instead of , and we could align with that.
Convergence would be helpful, do we know the status of the document?
Is this something that can be standardized in , even as a best practice or recommendation? Trying to align with all documents out there is not a long time strategy...
I've reached out to the OAuth WG on the topic of defining the field in DPoP itself. If that happens we can remove this field from our spec, but until that happens then it makes sense to keep FAPI and GNAP aligned, for now.
Regarding alignment between FAPI and GNAP... DPoP describes "htu" as while GNAP as which obviously isn't the same.
Change:
This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a <del> value that contained a wildcard prefix.  For other authorizations, it MUST be absent. </del> <ins> value that was a wildcard domain name.  For other authorizations, it MUST be absent.  Wildcard domain names are described in order- objects. </ins> The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").  The domain name MUST be encoded

Discussion:
badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:
Change:
Domain.  There may not be a Local Domain Registrar in all deployment scenarios. <ins> EST: Enrollment over Secure Transport VAR: Value Added Reseller </ins> 1.2. Two high level use cases are documented here.  There are more details provided in sections redirect2Registrar and voucher2EST.  While both use cases aid with incremental deployment of BRSKI infrastructure, for many smaller sites (such as teleworkers) no further <del> infrastructure are expected. </del> <ins> infrastructure is expected. </ins> The pledge is not expected to know which of these two situations it is in.  The pledge determines this based upon signals that it

Discussion:
[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?
Change:
The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout. <del> The probe timer is not set if the time threshold time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to </del> <ins> The probe timer MUST NOT be set if the time threshold time-threshold loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to </ins> spuriously retransmit data. 5.3.

Discussion:
I think this statement should be normative. Not sure if this is a design issue or not.
I'm comfortable with this being editorial.
Change:
2.1. Origins send a token challenge to clients in an "WWW-Authenticate" <del> header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. </del> <ins> header field with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. </ins> Origins that support this authentication scheme need to handle the following tasks:

Discussion:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list
Change:
5. <ins> To make a DNS API query, a DNS API client sends an HTTP request to the URI of the DNS API. </ins> The URI scheme MUST be https. <del> The path SHOULD be "/.well-known/dns-query" but a different path can be used if the DNS API Client has prior knowledge about a DNS API service on a different path at the origin being used.  (See iana for the registration of this in the well-known URI registry.)  Using the well-known path allows automated discovery of a DNS API Service, and also helps contextualize DNS Query requests pushed over an active HTTP/2 connection. </del> <ins> A client can be configured with a DNS API URI, or it can discover the URI.  This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI.  (See iana for the registration of this in the well-known URI registry.) DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. </ins> A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods.

Discussion:
Firstly, mention that the URI can be anything. Then explain why the well-known exists. The well-known URI exists for two reasons: to aid in discovery, for cases where the discovery process produces only a domain name (or domain name and port) to contextualize server pushes The first doesn't need a SHOULD.
The draft gets stuck into describing pieces of the URL, but neglects to point out some obvious things, like what the URL is for. It could probably use some more clarity about the configuration and discovery point as well.
Change:
transforms is that it allows a partly-trusted MD to decrypt, modify, and re-encrypt a packet.  When this is done, the cryptographic contexts used for decryption and re-encryption MUST use different, <del> independent master keys and master salts.  If the same context is used, the nonce formation rules for SRTP will cause the same key and nonce to be used with two different plaintexts, which substantially degrades the security of AES-GCM. </del> <ins> independent master keys.  If the same context is used, the nonce formation rules for SRTP will cause the same key and nonce to be used with two different plaintexts, which substantially degrades the security of AES-GCM. </ins> In other words, from the perspective of the MD, re-encrypting packets using this protocol will involve the same cryptographic operations as

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
establish the cryptographic context.  The same extension types MUST NOT appear in both the ServerHello and EncryptedExtensions. If the same extension appears in both locations, the client MUST <del> rely only on the value in the EncryptedExtensions block.  [[OPEN ISSUE: Should we just produce a canonical list of what goes where and have it be an error to have it in the wrong place?  That seems simpler.  Perhaps have a whitelist of which extensions can be unencrypted and everything else MUST be encrypted.]] </del> <ins> rely only on the value in the EncryptedExtensions block.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> Structure of this message:

Discussion:
Does it make sense to just have a tri-state column for TLS 1.3 on the extensions registry: "key" - key determining parameters "encrypted" - encrypted "forbidden" - not for use in TLS 1.3
"go" as in whether they are plaintext or go into the EncryptedExtensions block.
Change:
If the m= section proto value indicates use of SCTP: <del> If no SCTP association yet exists, prepare to initiate a SCTP </del> <ins> If an SCTP association exists, and the remote SCTP port has changed, discard the existing SCTP association.  This includes the case when the PeerConnection state is "have-remote- pranswer". If no valid SCTP association exists, prepare to initiate a SCTP </ins> association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote

Discussion:
ICE credentials, DTLS fingerprint and SCTP port are allowed to change, which is necessary to support sequential forking with pranswers.
I still need to read this all carefully but at first glance looks reasonable to me.
LGTM. NAME do you want to take another pass? NAME do you want to take a look?
LGTM