jiebi/CodeConvo huggingface dataset:
Change:
If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to <del> "application" and the <proto> field MUST be set to exactly match the field in the offer; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del> <ins> "application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer. </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an <del> "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in I-D.ietf-rtcweb-data-protocol. [OPEN ISSUE: the -01 of this document is missing this information.] </del> <ins> "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

Discussion:
Did not carefully review but looks fine to me
lgtm
Section 5.2.1 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. [OPEN ISSUE: the -01 of this document is missing this information.]
According to -07, a=sctpmap is no more, and replaced with a=fmtp, plus a=sctp-port. We still need to reference the appropriate string for the m= line.
Change:
registries and their allocation policies are below: TLS Cipher Suite Registry: Values with the first byte in the range <del> 0-254 (decimal) are assigned via Specification Required RFC2434. </del> <ins> 0-254 (decimal) are assigned via Specification Required RFC5226. </ins> Values with the first byte 255 (decimal) are reserved for Private <del> Use RFC2434. </del> <ins> Use RFC5226. </ins> IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are

Discussion:
RFC 5226 obsoleted RFC 2434 so we should refer to that to avoid a GENART review comment.
Change:
consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery. <del> This document aims to provide a taxonomy of networking issues as they relate to quality of experience in internet video delivery.  The focus is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common </del> <ins> This document examines networking issues as they relate to quality of experience in internet video delivery.  The focus is on capturing capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common </ins> assumptions in existing networking documents and observations of video delivery issues in practice. <del> Making specific recommendations for mitigating these issues is out of scope, though some existing mitigations are mentioned in passing. The intent is to provide a point of reference for future solution proposals to use in describing how new technologies address or avoid these existing observed problems. </del> <ins> Making specific recommendations on operational practices aimed at mitigating these issues is out of scope, though some existing mitigations are mentioned in passing.  The intent is to provide a point of reference for future solution proposals to use in describing how new technologies address or avoid these existing observed problems. </ins> 1.1.

Discussion:
Merged after discussion with NAME ...
This was a brillant ideq, and has worked in other groups, but I can't remember any contribution that was made using this template ...
We should probably talk about how to update This document aims to provide a taxonomy of networking issues as they relate to quality of experience in internet video delivery. The focus is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common assumptions in existing networking documents and observations of video delivery issues in practice. NAME might suggest this (but didn't put it in -05): This document focuses is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common assumptions in existing networking documents and observations of video delivery issues in practice. Thoughts from NAME or NAME
Sure, that works for me.
Change:
6. <del> 6.1. This registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established in RFC7235. </del> <ins> This document registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established in RFC7235. </ins> vapid

Discussion:
I know that it's the devil, but JSON is the obvious choice here.
Why would it be obvious ? application/x-www-form-urlencoded or a request parameter ?
It's an obvious choice given the proprietary precedence in the industry. I can't really judge the appropriateness of using JSON as opposed to an alternative -- this change LGTM assuming it is. Since the UA chooses the PS, there is no need for encryption. JSON provides good extensibility for additional (proprietary) data that may have to be transmitted over this channel.
At least it's not xml... I don't mind json - just didn't think it is so obvious. It does open an important question: will the user be allowed to pass more information to the push service (voluntarily) ? But +1 on this change.
Probably, but I don't want to think about that just yet :)
Change:
Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for <del> experimental and private use.  Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  In order to register an extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED. Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG Approval is REQUIRED for a Yes->No transition. </del> <ins> experimental and private use.  Therefore, IANA [SHALL change/has changed] the TLS Certificate Types regisry to: Change the registry policy to: Values with the first byte in the range 0-223 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 224-255 (decimal) are reserved for Private Use RFC8126. Add a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  In order to register an extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG Approval is REQUIRED for a Yes->No transition. </ins> See expert-pool for additional information about the designated expert pool.

Discussion:
Looks good
I think the TLS Certificate Type section should explicitly list the values for which "specification required" applies (and for which "reserved for private use" continues to apply).
Change:
request to the new-authorization resource specifying the identifier for which authorization is being requested. <del> The identifier that the account is authorized to represent: </del> <ins> The identifier to appear in the resulting authorization object (see authorization-objects) </ins> <del> The type of identifier. The identifier itself. </del> <ins> Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre- authorization cannot be used to authorize issuance with wildcard DNS identifiers. </ins> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the

Discussion:
Replaces
This text looks fine to me. I think there should be discussion in WGLC about this since folks that care about pre-authorization might be surprised by this new constraint.
Change:
new repositories for adopted Working Group items, or they might create repositories for individual documents on request. <del> All repositories for Working Group documents within the Working Group organization MUST be public.  Repositories for private documents MAY be kept private, but only where there is a specific reason for doing so.  For instance, a document that details a security vulnerability might be kept private prior to its initial publication as an Internet-Draft.  Once an Internet-Draft is published, repositories SHOULD be made public. </del> <ins> Maintaining private repositories for Working Group products is not recommended without specific cause.  For instance, a document that details a security vulnerability might be kept private prior to its initial publication as an Internet-Draft.  Once an Internet-Draft is published, repositories for Working Group documents MUST be made public. </ins> The adoption status of any document MUST be clear from the contents of the repository.  This can be achieved by having the name of the

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
5.10. <del> All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE.P1363.1998 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. </del> <ins> All ECDH calculations for the NIST curves (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE.P1363.1998 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. </ins> (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
allows the signaling to set up a separate media flow for each peer that it wishes to exchange media with.  In JSEP, this offer used in the UPDATE would be formed by simply creating a new PeerConnection <del> and making sure that the same local media streams have been added into this new PeerConnection.  Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in RFC3960. </del> <ins> (see sec.peerconnection) and making sure that the same local media streams have been added into this new PeerConnection.  Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in RFC3960. </ins> As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote

Discussion:
Build error looks like travis bustage
PeerConnection is used first at the next to last paragraph of section 3. Please add a reference at that point.
Yes.
Does Robert mean a ref to Section 4, or a ref to the W3C doc? We do have a ref to the W3C doc in Section 1.
That is why I concluded to S 4 (distinguishing between PC and RTCPC)
LGTM
Change:
each key/nonce pair MUST NOT be used to encrypt more than one message. <del> Keys, nonces and secrets of ratchets are derived using Derive-App- Secret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the </del> <ins> Keys, nonces and secrets of ratchets are derived using DeriveAppSecret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the </ins> ratchet tree is the same as the index of the leaf in the AS Tree used to initialize the sender's ratchet.

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. <del> An endpoint might consistently record RTT samples as 0 in extremely low latency networks, leading to a smoothed_rtt of 0.  Consequently, the endpoint could declare all earlier packets as lost immediately upon receiving an acknowledgement for a later packet.  That is, the endpoint would not provide any reordering tolerance.  To avoid declaring packets as lost too early, the time threshold MUST be set to at least kGranularity (defined in ld-consts-of-interest). </del> <ins> The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time multiplier, is 9/8. </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT

Discussion:
From a full read en route to Prague.
Thanks Jana, suggestions taken and "Clearer Loss Epoch" rewritten.
Change:
2.3. An application server requests the delivery of a push message as <del> described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field with credentials that use the "vapid" authentication scheme (auth). </del> <ins> described in RFC8030.  If the application server wishes to self- identify, it includes an Authorization header field with credentials that use the "vapid" authentication scheme (auth). </ins> Note that the example header fields in this document include extra line wrapping to meet formatting constraints.

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> 5. Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. 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> <ins> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, definitions of new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> <del> 6. </del> <ins> 4. </ins> Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires sending an HTTP/3 Settings parameter, it "sticks out".  In other

Discussion:
NAME thank you for the suggestions over on URL David and I worked through your proposal from top to bottom and turned it into this PR, which accepts many suggestions but not all. Please review and let us know if you're happy with it. NAME we believe some of your comments are addressed here too (unless tracked on a separate ticket). Please take a look.
While the argument in Section 2 "requests are strictly serialised in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. I would prefer to see this restriction as an argument here.
The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … During the IETF 113 discussions, I understood capsules as general mechanism reliable datagrams/wire encoding over HTTP In the draft however, Section 1 state "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." contradicts this impression. Can we clarify this?
Why is the ebnf instead of ? Should this allow request/upgrade methods to append a list of additional parameters?
Yes, allows parameters but does not. We didn't see a good reason to ban future parameters
Maybe you should mention it and require intermediaries to pass and ignore them in case they don't understand them.
as per recent changes in HTTPland specs, the ABNF adds confusion. My suggestion is to remove the ABNF. That might still leave a question over the structured types, but that is answered by the Structured Field value specs and we are unlikely to need to state anything ourselves. I can take a pass at this.
LGTM, thanks!
Change:
The configuration agent also selects a nonce length and an 16-octet AES-ECB key to use for connection ID decryption.  The nonce length MUST be at least 8 octets and no more than 16 octets.  The nonce <del> length and server ID length MUST sum to 19 or fewer octets. </del> <ins> length and server ID length MUST sum to 19 or fewer octets, but SHOULD sum to 15 or fewer to allow space for server use. </ins> 4.3.2.

Discussion:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.
Change:
client software can include these values in their code for a more efficient and compact request. <del> If desired, the AS MAY also generate and return some of these references dynamically to the client instance in its response to facilitate multiple interactions with the same software.  The client instance SHOULD use these references in future requests in lieu of sending the associated data value.  These handles are intended to be used on future requests. Dynamically generated handles are string values that MUST be protected by the client instance as secrets.  Handle values MUST be unguessable and MUST NOT contain any sensitive information.  Handle values are opaque to the client instance. All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the following dynamic handle return, additional handles can be defined in IANA. </del> <ins> If desired, the AS MAY also generate and return an instance identifier dynamically to the client instance in the response to facilitate multiple interactions with the same client instance over time.  The client instance SHOULD use this instance identifier in future requests in lieu of sending the associated data values in the "client" field. Dynamically generated client instance identifiers are string values that MUST be protected by the client instance as secrets.  Instance identifier values MUST be unguessable and MUST NOT contain any sensitive information.  Instance identifier values are opaque to the client instance. </ins> A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance. <del> This non-normative example shows one handle along side an issued access token. </del> <ins> This non-normative example shows an instance identifier along side an issued access token. </ins> [[ See issue #77 [18] ]]

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8641b302c594f5e2fd15576ceed1134a210465bd Inspect the deploy log: Browse the preview:
Change:
packet in the datagram. Every QUIC packet that is coalesced into a single UDP datagram is <del> separate and complete.  Though the values of some fields in the packet header might be redundant, no fields are omitted.  The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams.  For example, if decryption fails (because the keys are not available or any other reason), the receiver MAY either discard or buffer the packet for later processing and MUST attempt to process the remaining packets. </del> <ins> separate and complete.  The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams.  For example, if decryption fails (because the keys are not available or any other reason), the receiver MAY either discard or buffer the packet for later processing and MUST attempt to process the remaining packets. </ins> Retry packets (packet-retry), Version Negotiation packets (packet- version), and packets with a short header (short-header) do not

Discussion:
At the top of page 66 of the , we read: The second sentence seems to imply that a field could be omitted. Does this sentence sound odd to anyone else?
While it is perhaps technically redundant, I think it is actually quite helpful. The first sentence says, "complete" but that might be open to interpretation. The second sentence makes it clear what that means. I like it. YMMV :)
My issue is not with the redundancy of the second senteance, but rather with its meaning. The specification that "no fields be omitted" implies that fields could be omitted -- but they can't be: There are no optional fields in packet headers.
Maybe change the second sentence to something like:
NAME writes: The third sentence clarifies the first sentence well, too. I would just drop the second sentence altogether.
I can't remember now, but we did have an intermediate design where redundant fields were absent. This sentence may have crept in around then. I agree with NAME : it does seem redundant now.