jiebi/CodeConvo huggingface dataset:
Change:
<del> HTTP/3 and QPACK event definitions for qlog </del> <ins> HTTP/3 and QPACK qlog event definitions </ins> draft-ietf-quic-qlog-h3-events-latest Abstract

Discussion:
Fixes part of . The changes are tedious but also not too onerous. The main issue you have is that there's lots of comments here and there that break length limits. So I've just picked a line length that will appease xml2rfc. The changes you have in mind might have obviated the errors anyway. But if not, these changes will set a strong foundation to know how to shut xml2rfc up.
According to the official IETF draft guidelines, line length should not be longer than 72 ASCII characters (URL, and URL). For some reason, I had previously understood this to be 82 characters, and so the current texts are 10 characters too wide... Since this will be somewhat of a tedious process (which can be done largely automatically but with manual checks) which will impact allmost all parts of the documents, I propose we do this in a single burst somewhere down the line. cc NAME
Chatted a bit with rmarx offline. The errors that xml2rfc moans about are about artwork, not body text etc. Over the 3 PRs I created, there might look like a lot of churn but it is all constrained to the artwork pieces. In my opinion, it's better to fix these now (or nullify the json validation errors) so that we don't start ignoring things that exist or get newly introduced.
This should be fixed as of main-schema-02 and h3/quic-events-01. For future reference: hard limit of 72 is only needed inside "figures" (including code blocks!). Running text paragraphs/lists/etc. can be done by the tooling itself.
Change:
correspond to the properties given in transport-params and can only be queried. <del> Transport Features of the protocols that were selected, once the Connection has been established.  These features correspond to the properties given in transport-params and can only be queried. </del> <ins> Transport Features of the protocol stacks that were selected and instantiated, once the Connection has been established.  These features correspond to the properties given in transport-params and can only be queried.  Instead of preference levels, these features have boolean values indicating whether or not they were selected.  Note that these transport features may not fully reflect the specified parameters given in the pre-establishment phase.  For example, a certain Protocol Selection Property that an application specified as Preferred may not actually be present in the chosen Protocol Stack Instances because none of the currently available transport protocols had this feature. </ins> Protocol Properties of the Protocol Stack in use (see protocol- props below).  These can be set or queried.  Certain specific <del> procotol queries may be read-only, on a protocol and property </del> <ins> procotol queries may be read-only, on a protocol- and property- </ins> specific basis. Path Properties of the path(s) in use, once the Connection has

Discussion:
Appendix B of the API draft provides a sample concrete definition of the API, written in Go. Having concrete examples of the API is clearly useful, but I question whether this draft is the right place for them, since we don't want to bless a particular API variant. Suggest this appendix be moved to either the implementation draft, or a separate example API implementation draft.
The intention here is to show that the API is reasonably expressible and expressive in at least one modern language. I'd be more than happy to replace it with links to the code and documentation for now though. (Eventually, examples would be more useful than the sketch though.)
NAME makes sense.
Looks good to me.Looks good to me
Change:
4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del> <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media.

Discussion:
lgtm
need to be to "an" like in line 854?? URL
Fixed by
The word Blob is missing? URL
Change:
4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del> <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media.

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
3.3.1. <del> The client sends a POST request to "[leader]/upload_start" with the following message: The "task" field corresponds to the PA task for which a report will be generated. The leader responds to well-formed requests to "[leader]/upload_start" with status 200 and the following message: </del> <ins> The client sends a GET request to "[leader]/[version]/[task_id]/upload_start", where "[version] == PATask.version" and "[task_id] == PATask.id".  [TODO: Decide if adding the protocol version and task id to the URL is the right way to go.  Instead, we may want to make this a POST with a body that specifies the PATask.  (See issue#61.)] The leader respond with status 200 and the following message: </ins> The message includes the PA parameters the client will use to generate its report.  It also includes a protocol-specific message,

Discussion:
In we did away with the requirement for interaction between the client and leader. This PR resolves the issue by making the upload start request an idempotent GET.
Based on this week's design call (2021/7/7), "upload start" is likely going away altogether.
Change:
4. <del> 5. </del> TBD: Define a media type for JSONPath expressions. <del> 6. </del> <ins> 5. </ins> This section gives security considerations, as required by RFC3552.

Discussion:
There does not seem to be an appetite for doing the necessary spec work. This PR will test that assertion. Filter expressions are still supported, but not "container expressions", of the form [(...)].
I think this can be added later, similar to the consensus for . Personally I still see value in having it.
Change:
cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address.  Implementations <del> wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. </del> <ins> may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. </ins> 4.3.

Discussion:
As discussed, a couple of minor typos and corrections.
The travis failures here aren't Michael's fault.
I've looked up the missing reference dates and added them. Travis seems happier.
Change:
This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted <del> from various RFCs RFC7231 RFC6838 RFC5234 RFC8866. </del> <ins> from various RFCs I-D.ietf-httpbis-semantics RFC6838 RFC5234 RFC8866. [[replace: RFC editor: Please replace [RFC-httpbis-semantics] by what gets published from ]] </ins> 7.

Discussion:
7de7a76 Update the ABNF to refer to httpbis-semantics; include quoted-pair 7775765 Switch from 7230/7231 to httpbis-semantics 0a57952 Address the question Roman Danyliw did not ask :-)
Change:
Verify that the "group_id" is unique among the groups that the client is currently participating in. <ins> Verify that the "cipher_suite" in the GroupInfo matches the "cipher_suite" in the KeyPackage. </ins> Verify the integrity of the ratchet tree. Verify that the tree hash of the ratchet tree matches the

Discussion:
This will guarantee that all group members agree on the ciphersuite used. It gives more meaning to statements like "Each MLS session uses a single ciphersuite". Also, it prevents the following attack: the adversary (a malicious insider) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used. Now the new member uses a weaker scheme and the adversary can impersonate them.
Interim 2022-06-02: Agreement that more binding is better
Change:
[RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */ <del> 6.2. </del> <ins> 7.2. </ins> Instead of using CMP RFC4210, this specification refers to the lightweight CMP profile I-D.ietf-lamps-lightweight-cmp-profile, as it

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
The spin bit provides an additional method to measure per-flow RTT from observation points on the network path throughout the duration <del> of a connection.  Endpoint participation in spin bit signaling is </del> <ins> of a connection, following the principles of protocol measurability laid out in IPIM.  Endpoint participation in spin bit signaling is </ins> optional in QUIC.  That is, while its location is fixed in this version of QUIC, an endpoint can unilaterally choose to not support "spinning" the bit.  Use of the spin bit for RTT measurement by

Discussion:
I set the ready to merge label but there are merge conflict, so please don't merge before accepting my suggestions...
[Ding2015] and [IPIM] are in the references of the manageability draft, but aren't actually... referenced anywhere. That suggests either some text is missing or these entries are spurious.
Yes this has been already flagged by and is fixed in (which we will all merge on Monday when Brain is back). Thanks anyway!
Unused Reference: 'Ding2015' is defined on line 1272, but no explicit reference was found in the text Unused Reference: 'IPIM' is defined on line 1293, but no explicit reference was found in the text
Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'.
There are two paragraphs that include 2119-language: RFC 2119 keyword, line 578: '... RECOMMENDED. First, it only provid...' RFC 2119 keyword, line 969: '... NOT RECOMMENDED....' Should these be made lowercase or is a 2119 paragraph needed?
I see what was done. Looks ready to go.
Change:
Identical to the encrypted_record field in a TLS 1.3 record. <ins> As with previous versions of DTLS, mutliple DTLSCiphertext records can be included in the same underlying transport datagram. The short DTLS header format is: The short_epoch_and_sequence document contains the epoch and sequence packed into a 16 bit integer as follows: The first three bits are set to 001 in order to allow multiplexing between DTLS and VoIP protocols (STUN, RTP/RTCP, etc.)  RFC7983 and distinguish the short from long header formats. The fourth bit is the low order bit of the epoch value. The remaining bits contain the low order 12 bits of the sequence number. For deprotecion purposes, the nonce is computed using the full sequence number, which can be reconstructed as described in reconstructing. In this format, the length field is omitted and therefore the record consumes the entire rest of the datagram in the lower level transport.  It is not possible to have multiple DTLSShortCiphertext format records in the same datagram. DTLSShortCiphertext MUST only be used for data which is protected with one of the application_traffic_secrets, and not for either handshake or early data.  When using an application_traffic_secret for message protection, Implementations MAY use either DTLSCiphertext or DTLSShortCiphertext at their discretion. </ins> 4.1. DTLS uses an explicit sequence number, rather than an implicit one,

Discussion:
NAME PTAL
Oops. Thanks.
Sorry, I forgot to mention that I plan to do a separate PR for shrinking DTLS ciphertext. I have part of it in my buffer, but got this up and had to move on to something else for a bit.
I'm happy to defer fixing KeyUpdate, which is basically non-functional as it is. This is fine on that basis.
Change:
degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status <del> code 405 "Method Not Allowed" and type "malformedRequest". </del> <ins> code 405 "Method Not Allowed" and type "malformed". </ins> 6.4.

Discussion:
As suggested by David Hancock, change the certificate fetch examples to use POST-as-GET, noting that GET is optional As suggested by Felix Fontein, use the correct error code for "malformed" in the description of what servers should do in response to inappropriate GET requests
Since doesn't look like it will be merged anytime soon, would it be possible to move the editorial (undisputed) stuff (trailing comma, authz -> challenge in URL) into this PR?
NAME I think I've gotten all the trailing commas and errant headersgit di.
NAME Looks good to me!
editorial clarifications, looks good to me.
Change:
order using HTTP's multi-streaming functionality (RFC7540 Section 5}). <del> The Answer section of a DNS response contains one or more RRsets. </del> <ins> The Answer section of a DNS response can contain zero or more RRsets. </ins> (RRsets are defined in RFC7719.)  According to RFC2181, each resource <del> record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can have different TTLs, though it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The </del> <ins> record in an RRset has Time To Live (TTL) freshness information. Different RRsets in the Answer section can have different TTLs, although it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the RRset with the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS resource records in the Answer section reach a 0 TTL.  The </ins> response freshness lifetime MUST NOT be greater than that indicated <del> by the DNS Record with the smallest TTL in the response. </del> <ins> by the DNS resoruce record with the smallest TTL in the response. If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record.  Otherwise, the HTTP response MUST set a freshness lifetime (RFC7234 Section 4.2) of 0 by using a mechanism such as "Cache-Control: no-cache" (RFC7234 Section 5.2.1.4). </ins> A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

Discussion:
feel free to merge if my language works for you
I just now see you gave me the go ahead to merge. I'll fix the conflict and do so.
Change:
number space.  Separate packet number spaces ensures acknowledgement of packets sent with one level of encryption will not cause spurious retransmission of packets sent with a different encryption level. <del> Congestion control and RTT measurement are unified across packet number spaces. </del> <ins> Congestion control and round-trip time (RTT) measurement are unified across packet number spaces. </ins> 3.1.2.

Discussion:
Explicitly state that round trip time is abbreviated as RTT
In the recovery draft, RTT is briefly spelled out in section 5 but is used in several earlier sections. SRTT and PTO are not explained at all, it seems. TLP is spelled out. RTO has a section of its own but it referenced before that. The recovery doc cannot be a tutorial on transmission theory, but it would be helpful to list the key acronyms and possibly reference an RFC with more details. There are already sections summarising key variables in pseudocode. There are references at the end, but the reader would have to go through them all.
Yes, thanks for the note. I'm planning to do a cleanup of that doc soon.
I fixed defined RTT earlier in .
Change:
On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence <del> number.  The new ACK-eliciting Threshold and Update Max Ack Delay </del> <ins> number.  The new Ack-Eliciting Threshold and Update Max Ack Delay </ins> values MUST be immediately used for delaying acknowledgements; see sending.

Discussion:
Part of We still need to decide whether to change 'Update Max Ack Delay' to 'Max Ack Delay'.
Change:
key that needs to be used for decrypting. Both the frame counter and the key id are encoded in a variable <del> length format to decrease the overhead, so the first byte in the Sframe header is fixed and contains the header metadata with the following format: </del> <ins> length format to decrease the overhead.  The length is up to 8 bytes and is represented in 3 bits in the SFrame header: 000 represents a length of 1, 001 a length of 2... The first byte in the SFrame header is fixed and contains the header metadata with the following format: </ins> Reserved (R): 1 bit This field MUST be set to zero on sending, and MUST be ignored by receivers.  Counter Length (LEN): 3 bits This <del> field indicates the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length.  Key or Key Length: 3 bits This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. </del> <ins> field indicates the length of the CTR fields in bytes (1-8). Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length.  Key or Key Length: 3 bits This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. </ins> If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes: <del> Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </del> <ins> Frame counter byte length (LEN): 3bits The frame counter length in bytes (1-8).  Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> if X flag is 1 then KLEN is the length of the key (KID), that is found after the SFrame header metadata byte.  After the key id (KID), the frame counter (CTR) will be found in the next LEN bytes: <del> Key length (KLEN): 3 bits The key length in bytes.  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </del> <ins> Frame counter byte length (LEN): 3bits The frame counter length in bytes (1-8).  Key length (KLEN): 3 bits The key length in bytes (1-8).  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> 4.3.

Discussion:
PR fixes URL PR also updates AES-CTR test vectors accordingly. PR clarifies that decryption ought to work but comparing encrypted data may sometimes fail.
The spec says: Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes. This probably means 000 is 1 byte, 001 is 2 bytes, and so on... It would be good to clarify this.