jiebi/CodeConvo huggingface dataset:
Change:
The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection.  It then responds with <del> its own ServerHello, which indicates the negotiated connection parameters. [server-hello].  The combination of the ClientHello and the ServerHello determines the shared keys.  If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral Diffie-Hellman share which MUST be in the same group as one of the client's shares.  If PSK key establishment is in use, then the ServerHello contains a "pre_shared_key" extension indicating which of the client's offered PSKs was selected.  Note that implementations can use (EC)DHE and PSK together, in which case both extensions will be supplied. </del> <ins> its own ServerHello (server-hello), which indicates the negotiated connection parameters.  The combination of the ClientHello and the ServerHello determines the shared keys.  If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral Diffie-Hellman share which MUST be in the same group as one of the client's shares.  If PSK key establishment is in use, then the ServerHello contains a "pre_shared_key" extension indicating which of the client's offered PSKs was selected.  Note that implementations can use (EC)DHE and PSK together, in which case both extensions will be supplied. </ins> The server then sends two messages to establish the Server Parameters:

Discussion:
Most of these are simple enough, kramdown treats all bracketed text as a reference. So these can be replaced with and the warnings go away. The biggest change here is slightly stylistic: a few places had , which kramdown complained about, but rendered correctly. However, this produced a non-sentence. Also, I fixed some inconsistent use of references and s/data/date in one of the references.
See comment
Change:
The IV is 128 bits long and calculated from the CTR field of the Frame header: <del> 3.2.2. 3.2.2.1. SFrame supports two ciphers, the only difference is the length of the authentication tag, where 10 bytes is used for video and 4 bytes for audio 1- AES_CM_128_HMAC_SHA256_80 2- AES_CM_128_HMAC_SHA256_32 It uses AES counter mode for encryption with 128 bit key, SHA256 hash for the HKDF key derivation. 3.2.2.2. SRTP is used as an outer encryption, since the media payload is already encrypted, and SRTP only protects the RTP headers, one implementation could use 4 bytes outer auth tag to decrease the overhead, however it is up to the application to use other ciphers like AES-128-GCM with full authentication tag. It is possible that future versions of this draft will define other ciphers. 3.2.3. </del> <ins> 3.3.2. </ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
_RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.4. </del> <ins> 7.4. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230.

Discussion:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility
Change:
temporary access to the peer's private key from pre-computing valid authenticators. <del> The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in Section 4.2. of TLS13 and the server_name RFC6066 extension, which is allowed for client-generated authenticator requests. </del> <ins> The set of extensions allowed in the CertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column.  The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column, along with the server_name RFC6066 extension. The uniqueness requirements of the certificate_request_context apply only to CertificateRequest and ClientCertificateRequest messages that are used as part of authenticator requests.  There is no impact if the value of a certificate_request_context used in an authenticator request matches the value of a certificate_request_context in the handshake or in a post-handshake message. </ins> 5.

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

Discussion:
So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!
Change:
security level of the curves. The mandatory-to-implement ciphersuite for MLS 1.0 is <del> "MLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Ed25519 for signatures. </del> <ins> "MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Ed25519 for signatures. </ins> Values with the first byte 255 (decimal) are reserved for Private Use.

Discussion:
proposes to remove redundancy between version fields and ciphersuites by removing the version fields. This PR removes the version from the ciphersuite instead.
NAME suggests adding some advisory text in the extensibility section to the effect that future versions of the protocol should consider whether they want to keep all defined ciphersuites.
NAME here is some text we put in RFC 8447 (IANA registries for TLS) that was also included in the IANA registry to warn about cipher suites getting weaker over time. This could be modified to mention culling at different version. WARNING: : Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
Affiliation -> Meta Platforms Address -> EMAIL
In , the field of is removed. I'm guessing the reason was that is was redundant with the ciphersuite, since the MLS version is at the time included in the ciphersuite. However, in , MLS versions were removed from ciphersuites, making the protocol version not redundant anymore with the ciphersuite. We should probably put the MLS version back there?
I just discovered that this is then fixed by adding the MLS version to in , closing.
Change:
different entities, as shown in the figure below.  As with the joint Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment <del> depend on the issuance protocol. </del> <ins> depend on the issuance protocol and relationship between Attester and Issuer. </ins> This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth <del> pointing out that the some scenarios proposed may be relevant to other wireless telecommunication systems.  As one example, the generic architecture proposed in fig:sat_gateway may be mapped to cellular networks as follows: the 'network function' block gather some of the functions of the Evolved Packet Core subsystem, while the 'access gateway' and 'physical gateway' blocks gather the same type of functions as the Universal Mobile Terrestrial Radio Access Network.  This mapping extends the opportunities identified in this draft since they may be also relevant for cellular networks. </del> <ins> pointing out that some scenarios proposed may be relevant to other wireless telecommunication systems.  As one example, the generic architecture proposed in fig:sat_gateway may be mapped to cellular networks as follows: the 'network function' block gather some of the functions of the Evolved Packet Core subsystem, while the 'access gateway' and 'physical gateway' blocks gather the same type of functions as the Universal Mobile Terrestrial Radio Access Network. This mapping extends the opportunities identified in this draft since they may be also relevant for cellular networks. </ins> 7.

Discussion:
A few document nits… Section 2, 1st and 2nd Sentences “in satellite system” should be “in a satellite system”. Not clear what “lays” means here. “multi-gateway satellites network” should be “multi-gateway satellite network”. (Most of the uses cases have nothing to do with multi-gateway, though.) Section 3, 2nd Sentence Delete the duplicate “where”. Section 6, 2nd Sentence “that the some scenarios” should be “that some scenarios”.
Thanks for having identified the NITS. Closed by PR
Change:
6.4. <del> Recovery is a period of time beginning with detection of a lost packet or an increase in the ECN-CE counter.  Because QUIC does not retransmit packets, it defines the end of recovery as a packet sent after the start of recovery being acknowledged.  This is slightly different from TCP's definition of recovery, which ends when the lost packet that started recovery is acknowledged. </del> <ins> A recovery period is entered when loss or ECN-CE marking of a packet is detected.  A recovery period ends when a packet sent during the recovery period is acknowledged.  This is slightly different from TCP's definition of recovery, which ends when the lost packet that started recovery is acknowledged. </ins> The recovery period limits congestion window reduction to once per round trip.  During recovery, the congestion window remains unchanged

Discussion:
I'm happy to merge this as is, but I'll give it 24hrs in case others have comments.
This is weird in that it assumes some context that isn't provided: Perhaps instead: This "Because QUIC does not retransmit packets" thing is unnecessary. I'll open a PR.
Change:
leaf, or appended to the right edge of the tree if all leaves are occupied. <del> Process the "path" value using the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret": </del> <ins> Verify that the "path" value is populated if either of the "updates" or "removes" vectors has length greater than zero, or if all of the "updates", "removes", and "adds" vectors are empty. Otherwise, the "path" value MAY be omitted. If the "path" value is populated: Process the "path" value using the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret": </ins> Apply the DirectPath to the tree, as described in synchronizing-views-of-the-tree, and store "key_package" at the

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.
Change:
simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. <ins> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. </ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.
Change:
around that ecosystem.  However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth <del> 2.0 cannot easily or cleanly address.  Even so, GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example- oauth2. </del> <ins> 2.0 cannot easily or cleanly address. vs-oauth2 further details the protocol rationale compared to OAuth 2.0.  GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example-oauth2. </ins> 1.1.

Discussion:
Fixes issue Note : in the appendix, I used "OAuth 2", elsewhere we talk about "OAuth 2.0". Maybe needs some adjustements.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 40ad74b8eeec1229a14c83324dbcce73533365d9 https://deploy-preview-247--gnap-core-protocol-editors-URL
For the RFC to be self-contained, please add a section to the Introduction (or an appendix) summarizing the main changes from OAuth2/OIDC, and the rationale for each delta. (Originally raised by NAME
Suggest to put this area in the wiki to have a deeper explanation
I've started a wiki page with some content I had written up for another publication: URL
This information is important to the draft's readership, and people are not seeing it (e.g., Denis's mail from March 26). Can we include it as-is in an appendix to the draft?
I will submit a PR as an appendix. Note also that the editors prepared a short paper "Managing authorization grants beyond OAuth 2" that has been accepted at . It was a nice way to get some external reviews. Will be published in
Looks good, just one typo to fix before inclusion.
Change:
This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <ins> 0xffd277 (note that this will switch to a lower value before publication) H3_DATAGRAM 0 provisional (permanent if this document is approved) This Document IETF HTTP_WG; HTTP working group; ietf-http-wg@w3.org </ins> 8.2. This document will request IANA to register the following entry in

Discussion:
The HTTP/3 spec was "contracted out to the QUIC WG", but the registries it establishes are given back to the the HTTP WG are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (EMAIL). This spec defines some new registries, it isn't clear to me which WG would "own" the registry after we are done with this spec.
Technically, IANA registries aren't owned by Working Groups. But adding the HTTP working group as a contact for the initial entries sounds fine by me. But I'd prefer to put this on hold until we're closer to publication.
WFM!
Change:
extension, as described in I-D.ietf-mmusic-msid, Section 3.2. For each specified payload type, establish a mapping between <del> the payload type ID and the actual media format, as descibed in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del> <ins> the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload

Discussion:
This is all strictly editorial and I think if either of you give it a quick scan, you can just merge it
LGTM - will merge
Change:
value generated at that time, and the Verifier decides that it can trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) < <del> Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del> <ins> Threshold". The threshold is decided by the Appraisal Policy for Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. </ins> The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)

Discussion:
Clarify that recentness of Evidence depends primarily on the appraisal policy and that clock skew is only secondary.
Section "16.1. Example 1", third para: I find the reference to clock skew slightly confusing. The Threshold value here is more likely to depend on a verification policy that defines what is an acceptable "age" of the sampled claim rather than on considerations about clocks drifting.