jiebi/CodeConvo huggingface dataset:
Change:
many active commitments exist and how quickly the commitments are being rotated.  Clients SHOULD reject configurations/commitments that violate their requirements for avoiding user segregation.  These <del> considerations are discussed as part of draft-davidson-pp- </del> <ins> considerations are discussed as part of draft-ietf-privacypass- </ins> architecture. 3.2.

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
Stealth server Stub resolver Subdomain <ins> Subordinate Superordinate </ins> T TLD

Discussion:
In June 2015, Joe Abley said: I think that "superordinate" and "subordinate" might be worth mentioning here, with reference to their definitions in EPP.
Added in URL
I think this is ok. Friendly amendment is to note that these are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. (But I don't know that we need to do this, hence the approval.)
Change:
3.8.1. <del> "$["u00b1"]" is normalized into (noise in the table and lack of typewriter font is due to RFCXMLv3 limitations). </del> 4. 4.1.

Discussion:
Fixes URL
Do we intend to replace this with anything? What is its purpose in being here?
The N-1 line also illustrates the point so I think it's probably OK to leave it?
Sorry, I didn't pay attention. The purpose of this example was to show that escaped characters are normalized into their actual equivalents (unless there is a reason not to do so). The messiness is a workaround for xml2rfc bugs. I'm confident we can get these bugs fixed before this is published; otherwise we might indeed want to skip this example.
Why doesn't the example already show that an escaped character is normalised into its actual equivalent ("a")?
It does. Many implementers will however think that this only applies to 95-ASCII characters (there is no reason for thinking that, but it is a highly likely misunderstanding).
The last entry in table 15 is completely incomprehensible and the explanation in the following paragraph doesn't help. Not sure how to work around this within the limitations of xml2rfc but maybe just leave it out, it's implicit in the 2nd-last-line example.
NAME I presume you are referring to with the caption "Normalized Path examples". (Table 15 at is a different one.) I agree the example is a mess and doesn't pull its weight, so I'll submit a PR to delete it.
I think it is useful to have an example that shows characters are not normally escaped, even if they are beyond ASCII.
(By the time this goes by the RFC editor, we may be able to get rid of the useless U+.... stuff added by xml2rfc.)
Change:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. </del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature.

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently <del> routes packets to the correct server instance.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  This ensures that there is no need to for servers and infrastructure to coordinate routing information for each connection. See QUIC-LB for more information. </del> <ins> routes packets to the server instance that has the connection state, even if addresses, ports, and/or connection IDs change.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  For an example of this technique, see QUIC-LB. </ins> 10.2.

Discussion:
Does this make it easier to understand?
NAME is this better?
“Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the correct server instance. “ could this be: “Server deployments with load balancers and other routing infrastructure that depends on observing the payload of IP packets need to ensure that this infrastructure consistently routes all the QUIC packet belonging to a connection to the same server instance.” Seems like that is helpful. Is there a relevant section in the OPS draft where the reader should be directed?
Not sure if you addition of "that depends on observing the payload of IP packets" is that helpful in the sentence. The whole point here that if you use load balancers with QUIC, looking only at the IP might not be enough. NAME can you have a look how to phrase this?
Is this referring to sec 9.1 of the applicability draft? Why refer to the ops draft when the current reference (QUIC-LB) has everything you would want to know about the subject? I don't understand what Gorry's new clause adds. In fact, the IP address is not in the payload so I don't believe it's even accurate. Are you trying to distinguish between L7 and L4 load balancers here?
I couldn't work out what the current sentence means what does "correctly" mean?
OK, I can reword this.
This is left open as there is a pending rewrite of the NAT section.
looks good to me.
Change:
RFC5280 specifies several extended key usages for X.509 certificates. This document defines a general purpose document signing extended key <del> usage for X.509 public key certificates which restricts the usage of </del> <ins> usage for X.509 public key certificates which specifies the usage of </ins> the certificates for document signing. 1. <del> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been addedRFC7299 as public OID under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp- emailProtection, id-kp-codeSigning or vendor defined Object ID for general document signing purposes. </del> <ins> RFC5280 specifies several extended key purpose identifiers for X.509 certificates.  In addition, several extended key purpose identifiers were addedRFC7299 as public OIDs under the IANA PKIX Extended key purpose identifiers arc.  While usage of the any extended key usage value is bad practice for publicly trusted certificates, there is no public and general extended key purpose identifier explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object IDs for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
new epoch to be received prior to the completion of a handshake.  For instance, the server may send its Finished message and then start transmitting data.  Implementations MAY either buffer or discard such <del> packets, though when DTLS is used over reliable transports (e.g., </del> <ins> records, though when DTLS is used over reliable transports (e.g., </ins> SCTP RFC4960), they SHOULD be buffered and processed once the <del> handshake completes.  Note that TLS's restrictions on when packets may be sent still apply, and the receiver treats the packets as if </del> <ins> handshake completes.  Note that TLS's restrictions on when records may be sent still apply, and the receiver treats the records as if </ins> they were sent in the right order. Implementations MUST send retransmissions of lost messages using the

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
Below is an example exchange for DTLS 1.3 using a single CID in each direction. <del> Note: The connection_id extension is defined in DTLS-CID, which is used in ClientHello and ServerHello messages. </del> <ins> Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. </ins> If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID.

Discussion:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.
Change:
3.3. Because QUIC is encapsulated in UDP, applications using QUIC must <del> deal with short idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry will be expired after just thirty seconds of inactivity. </del> <ins> deal with short network idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP. RFC5382 suggests a TCP idle period of at least 124 minutes, though there is not evidence of widespread implementation of this guideline in the literature.  Short network timeout for UDP, however, is well- documented.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity.  Section 3.5 of RFC8085 further discusses keep-alive intervals for UDP: it requires a minimum value of 15 seconds, but recommends larger values, or omitting keepalive entirely. </ins> By using a Connection ID, QUIC is designed to be robust to NAT address rebinding after a timeout.  However, some QUIC connections

Discussion:
"Idle period", "network idle timeout", and "idle timeout" are distinct; addresses a comment in .
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by
Change:
6.3.1.5.3. <del> The known_configuration extension allows the client to indicate that it wishes to reuse the server's known configuration and semi-static (EC)DHE key (see server-configuration for how to establish these configurations.  This extension allows the omission of the server certificate and signature, with three potential benefits: </del> <ins> The "known_configuration" extension allows the client to indicate that it wishes to reuse the server's known configuration and semi- static (EC)DHE key (see server-configuration for how to establish these configurations.  This extension allows the omission of the server certificate and signature, with three potential benefits: </ins> Shortening the handshake because the certificate may be large.

Discussion:
Some fixes for things I didn't catch when I checked for typos in the big patch last time. Of note, you're missing a closing brace for the select in "PreSharedKeyExtension" and a semicolon after "KnownConfigurationExtension". I also corrected things to match the existing (admittedly unusual) indentation style of the document and put quotes around the extension IDs you missed. (some had them; some didn't)
Ok, spaces between cases reverted. I also added a similar bit of whitespace in another new extension.
Change:
simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2. <ins> It is possible for both Media Servers and WHIP clients to support Scalable Video Coding (SVC).  However, as there is no universal negotiation mechanism in SDP for SVC, the encoder must consider the negotiated codec(s), intended usage, and SVC support in available decoders when configuring SVC. </ins> 4.7. In order to support future extensions to be defined for the WHIP

Discussion:
From NAME Simulcast and scalable video coding Both Simulcast [RFC8853] and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. [BA] K-SVC and “S” modes are different. K-SVC denotes the KEY and KEY_SHIFT modes, whereas “S” modes denote the encapsulation of multiple encodings within a single SSRC, as is supported in VP9 and AV1. Diagrams of the various modes are included in the WebRTC-SVC specification: URL Also, SVC is not negotiated within Offer/Answer in WebRTC. It is something that the encoder can just turn on. At least for temporal modes (L1T2, L1T3) ingester support can often be taken for granted. While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode, in practice there are VP9 and AV1 hardware decoders that cannot decode spatial scalability because they do not support spatial references (e.g. a P-frame at a higher resolution than the P or I frame that it references). This nasty little “wrinkle” required us to define the “spatialScalability” attribute in Media Capabilities, to allow applications to discover whether a (hardware) decoder supports spatial scalability or not: Media Capabilities URL Not sure if you want to get into this in the specification. Issues are most likely to be encountered where hardware-based transcoders are used (but in that scenario, spatial scalability probably wouldn’t be relevant anyway),
Change:
5.1. <del> Some TLS 1.3 extensions can be quite large, thus repeating them in the ClientHelloInner and ClientHelloOuter can lead to an excessive overall size.  One pathological example is "key_share" with post- quantum algorithms.  To reduce the impact of duplicated extensions, the client may use the "ech_outer_extensions" extension. OuterExtensions consists of one or more ExtensionType values, each of which reference an extension in ClientHelloOuter.  The extensions in OuterExtensions MUST appear in ClientHelloOuter in the same relative order, however, there is no requirement that they be continguous. For example, OuterExtensions may contain extensions A, B, C, while ClientHelloOuter contains extensions A, D, B, C, E, F. The "ech_outer_extensions" extension is only used for compressing the ClientHelloInner.  It can only be included in EncodedClientHelloInner, and MUST NOT be sent in either ClientHelloOuter or ClientHelloInner. When sending ClientHello, the client first computes ClientHelloInner, including any PSK binders.  It then computes a new value, the EncodedClientHelloInner, which is the following structure: </del> <ins> Before encrypting, the client pads and optionally compresses ClientHelloInner into a EncodedClientHelloInner structure, defined below: </ins> The "client_hello" field is computed by first making a copy of ClientHelloInner and setting the "legacy_session_id" field to the

Discussion:
Inspired by NAME . We can go further and just completely define EncodedClientHelloInner first.
Change:
packet protection. A client only receives acknowledgments for its 0-RTT packets once the <del> handshake is complete.  Consequently, a server might expect 0-RTT packets to start with a packet number of 0.  Therefore, in determining the length of the packet number encoding for 0-RTT packets, a client MUST assume that all packets up to the current packet number are in flight, starting from a packet number of 0. Thus, 0-RTT packets could need to use a longer packet number encoding. </del> <ins> handshake is complete. </ins> A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot

Discussion:
I noticed the 0-RTT specific text in and thought a general clarification would be better. Conveniently, I don't think anyone has gotten this wrong in their implementation.
Thanks Ian, this is much clearer.
Change:
The queries and responses must be able to be flexible enough to express every normal DNS query. <del> The protocol must allow implementations to use HTTP's content negotiation mechanism. </del> <ins> The protocol must permit the addition of new formats for DNS queries and responses. </ins> The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to

Discussion:
Conneg is a means, not an end.
this is a good change. I'm good if paul is good.
Change:
payload data. Moreover, while encryption (in this case TLS) is inseparably <del> integrated with QUIC, TLS negotiation over TCP can be blocked.  In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable. </del> <ins> integrated with QUIC, TLS negotiation over TCP can be blocked.  If TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. </ins> 3.

Discussion:
I think the following sentence has issues: “In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable.” I’m not sure I understand “In case” I’m not sure this should be upper case RFC2119, unless we decide to also make normative recommendations in other places. “allowing”..”unavailable” makes this award to read.
2119 issue also noted in .
Change:
Otherwise, ignore the candidate. <del> Multicast DNS resolution might end up retrieving both an IPv4 and IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. </del> <ins> An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a ".local" name may happen through Unicast DNS, see RFC6762 section 3. An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. </ins> 3.

Discussion:
Some additional comments may be needed in the prflx section?
NAME I went ahead and added a commit for my proposed changes. Let me know if the proposed changes are fine with you.
NAME Did you only commit the html changes? Can you include the markdown?
Oh, I probably messed up with the commit. I was expecting to commit only the markdown. I'll fix it.
It is conceivable that a server would implement ICE with mDNS candidates. There should be nothing in the ICE candidate processing that prevents this from working. Therefore we should call out what should happen when an mDNS query returns multiple IP addresses. E.g. use the 'best' on (where IPv6 is better than IPv4)?
This is a complex area. A simpler option could be that we mandate 1:1 for mDNS, and/or pick the first address of the expected type.
Mandating 1:1 for mDNS in the context of WebRTC is probably the straightforward approach. We should probably also define the behavior in the case of multiple responses, picking the first record makes sense to me. This requirement causes a potential issue when using MDNS for non default route though: it creates a fingerprinting vector by counting the number of different MDNS names for a given peer connection. I am not sure what reliable means we have to know the expected type of the address and whether this is a requirement at all. The easy solution would be to include this information in the MDNS name.
Good point about type not being known a priori, and we could put a hint in the name. Another option could be to resolve the name before forming pairs, take the first record found, and then only pair the resolved address with local candidates of the appropriate family.
Fixed by
LGTM with one comment