jiebi/CodeConvo huggingface dataset:
Change:
before or during Connection establishment, see also send- idempotent.  It is given in Bytes. <ins> In order to specify Specific Protocol Properties, the application can attach a set of options to the Preconnection object, associated with a specific protocol.  For example, the application could specify a set of TCP Options to use if and only if TCP is selected by the system, including options such as the Maximum Segment Size (MSS), and options around Acknowledgement Stretching.  Such properties should not be assumed to apply across different protocols, but must be possible to specify if required by the application. </ins> 5.2.3. Application Intents are a group of properties expressing what an

Discussion:
This addresses
Section 5.2.2. of the API should include the concept from the architecture of Specific Protocol Properties. I think expecting that all of these timeout/etc values should be the same no matter what protocol is selected is limiting, and a bit naive. I know as an application, for example, that I may need to do more keep alive activity to make NATs happy for UDP-based protocols than for TCP-based protocols (where are you, PLUS?!). Just a quick paragraph to indicate that the API can allow protocol-specific options to tune based on what is ultimately selected would be good.
let's race candidate authors for this paragraph ;) those who do not charter working groups for good ideas are doomed to forever reinvent them poorly.
Is 5.2.2 supposed to be the Specific Protocol Properties section? This section also seems to be a mix of things right now. I think this needs to be fixed as part of a bigger rework of section 5.2.
Agreed. Check out my pull request—I switch the text to talking about the architecture concepts of Generic Protocol Properties and Specific Protocol Properties.
That is better, but just a partial fix. I think we should get rid of the term Transport Preferences and the content of 5.2.1 and 5.2.2 needs to be reshuffled. Most of what is in 5.2.1 reads as protocol properties to me so I do not understand the current split.
That's fine with me. We could merge this PR in, and then as Brian does a pass, we can clean the rest up.
lgtm
Change:
8.2. <del> We highlighted previously that short key-cycles can be used to reduce client privacy.  However, regular key rotations of the issuing key are still recommended to maintain good server key hygiene. We recommend that Privacy Pass issuing keys are rotated from anywhere between 1 and 12 weeks.  With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. 8.3. </del> When a client holds tokens for an server, it is possible for any verifier to invoke that client to redeem tokens for that server. This can lead to an attack where a malicious verifier can force a

Discussion:
cc NAME NAME
Yeah, I agree. Something to bring up for discussion.
LGTM, 1 week might still be too small of a window for actively malicious servers, but I think that ties in to the open issue regarding malicious servers rather than the generic key rotation considerations.
Change:
and WebRTC is no exception.  Specifically, sites can use the presence or absence of specific devices as a browser fingerprint.  In general, the API needs to be balanced between functionality and the <del> incremental fingerprint risk.  See Fingerprinting </del> <ins> incremental fingerprint risk.  See Fingerprinting. </ins> 5.

Discussion:
Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.
Change:
The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. <del> The TokenRequest.blinded_msg is of the correct size. </del> <ins> The TokenRequest.blinded_request is of the correct size. </ins> If any of these conditions is not met, the Issuer MUST return an HTTP <del> 400 error to the Client, which will forward the error to the client. </del> <ins> 400 error to the client. </ins> 5.2. <del> If the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </del> <ins> Upon receipt of a TokenRequest, the Issuer tries to deseralize TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of OPRF, yielding "blinded_element".  If this fails, the Issuer MUST return an HTTP 400 error to the client.  Otherwise, if the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </ins> <del> SetupPOPRFServer is in OPRF, Section 3.2 and Evaluate is defined in OPRF, Section 3.3.3.  The Issuer then creates a TokenResponse </del> <ins> SetupVOPRFServer is in OPRF, Section 3.2 and Evaluate is defined in OPRF, Section 3.3.2.  The Issuer then creates a TokenResponse </ins> structured as follows: The structure fields are defined as follows: <del> "evaluate_response" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluated_msg)". </del> <ins> "evaluate_msg" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluate_element)". </ins> "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as

Discussion:
Since metadata can be bound to tokens via TokenChallenge.redemptioncontext, and the origin is ultimately the one who determines what metadata is supported, there's no more real need for the issuer_ to supply this metadata. So let's go with the simpler VOPRF protocol instead! Test vectors generated from the code here: URL cc NAME NAME NAME
LGTM
Change:
An ordered collection of HTTP field lines associated with an HTTP message.  A field section can contain multiple field lines with the same name.  It can also contain duplicate field lines.  An <del> HTTP message can include both header field and trailer field sections. </del> <ins> HTTP message can include both header and trailer sections. </ins> An instruction that represents a field line, possibly by reference to the dynamic and static tables.

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?
Change:
given task.  If the leader receives a report from a client whose nonce is in this set, it simply ignores it.  A helper who receives an encrypted input share whose nonce is in this set replies to the <del> leader with an error as described in collect-flow. </del> <ins> leader with an error as described in input-share-batch-validation. </ins> [OPEN ISSUE: This has the potential to require aggreagtors to store nonce sests indefinitely.  See issue#180.]

Discussion:
This fixes a reference that was pointing at the wrong section. The behavior relating to is under "Input Share Validation".
Change:
The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: <del> The "wq-draft01" label identifies QUIC used as a protocol for </del> <ins> The "wq-vvv-01" label identifies QUIC used as a protocol for </ins> WebTransport: QuicTransport <del> 0x77 0x71 0x2d 0x64 0x72 0x61 0x66 0x74 0x30 0x31 ("wq-draft01") </del> <ins> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") </ins> This document 8.2. <del> The following entry is added to the "QUIC Transport Parameter Registry" registry established by QUIC-TRANSPORT: </del> <ins> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the following fields: </ins> <del> The "web_accepted_origins" parameter allows the server to indicate origins that are permitted to connect to it: </del> <ins> The name of the field. </ins> <del> 0xffc8 </del> <ins> The 16-bit uniquie identifier that is used on the wire. </ins> <del> web_accepted_origins </del> <ins> A brief description of what the parameter does. </ins> <del> This document </del> <ins> The document that describes the parameter. The IANA policy, as descrbied in RFC8126, SHALL be Standards Action for values between 0x0000 and 0x03ff; Specification Required for values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. 9.  References 9.1.  URIs [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin </ins>

Discussion:
What is the uri-scheme used in an origin? ( It may be discussed as a separate issue.
Well, the origin sent here is the origin of the webpage that created QuicTransport; so, for instance, if connects using QuicTransport to , the origin send would be . I don't think a QuicTransport connection can be an origin by itself. We are currently considering giving it its own URL scheme, but a URL can only act as an origin if a user can to it, or if the URL has storage attached to it (which QuicTransport doesn't, since it doesn't support HTTP cookies).
I misunderstood the URI schema as that of QuicTransport itself Your kind explanation made me understand. thanks
Change:
manifest with key establishment provided by the hybrid public-key encryption (HPKE) scheme and the AES Key Wrap (AES-KW) with a pre- shared key-encryption key.  Encryption of the firmware image is <del> encrypted using AES-GCM or AES-CCM. </del> <ins> accomplished using the established content encryption key and a mutually agreed symmetric encryption algorithm, such as AES-GCM or AES-CCM. </ins> 1.

Discussion:
Based on discussions with Russ, I have updated the text in Section 7 about CEK Verification. Text about the parameters used for encryption were missing.
Change:
RFC4566 is the base SDP specification and MUST be implemented. <del> RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RTP profile. </del> <ins> RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE

Discussion:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm
Change:
for the Content-Format Field (label "ct") within its range.  The range of the base field includes the Record containing it, up to (but not including) the next Record containing a "bct" field, if any, or <del> up to the end of the pack otherwise.  Resolution (Section 4.6 of RFC8428) of this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field. </del> <ins> up to the end of the pack otherwise.  Resolution (RFC8428) of this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field. </ins> 5.

Discussion:
Alexey notes (Archived-At: ): Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference. (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.) This course of action would probably delay data-ct a bit; we might counteract the damage by early registration. Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.
I didn't do thorough review of the ABNF but otherwise looks good to me Hi all, Sorry for the belated review. I think the document is nearly ready for progression. I have a couple of minor related issues: Terminology Readers should also be familiar with the terms and concepts discussed in [RFC8428]. Awareness of terminology issues discussed in [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it should be revived. (Or see below) helpful. SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document. Best Regards, Alexey
Change:
sections.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (malformed). <del> All pseudo-header fields MUST appear in the header field section before regular header fields.  Any request or response that contains a pseudo-header field that appears in a header field section after a regular header field MUST be treated as malformed (malformed). </del> <ins> All pseudo-header fields MUST appear in the header section before regular header fields.  Any request or response that contains a pseudo-header field that appears in a header section after a regular header field MUST be treated as malformed (malformed). </ins> The following pseudo-header fields are defined for requests:

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?
Change:
latency is close to zero, the probability is high that the two peers are running on the same device. <del> To avoid this issue, browsers SHOULD NOT register Multicast DNS names for WebRTC applications running in a third-party browser execution </del> <ins> To avoid this issue, browsers SHOULD NOT register mDNS names for WebRTC applications running in a third-party browser execution </ins> context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. 4. <del> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate. ICESDP section 4.1 could be updated to explicitly allow Multicast DNS names in the connection-address field. </del> <ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. </ins> <del> The proposal relies on adding the ability to register Multicast DNS names at ICE gathering time.  This could be described in ICESDP and/ or WebRTCSpec. </del> <ins> The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. </ins> The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the <del> default mode could be defined as mode 3 with Multicast DNS based ICE </del> <ins> default mode could be defined as mode 3 with mDNS-based ICE </ins> candidates.

Discussion:
Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.
Change:
name actually queried or else the last name in a CNAME chain response. <del> [[ This text is being modified in the WG and a changed definition will appear in a future draft. ]] Data from the authority section of a non-authoritative answer. RFC1035 Section 2.1 defines "authoritative" data.  However, referrals at zone cuts (defined in zones) are not authoritative. Referrals may be zone cut NS resource records and their glue records.  NS records on the parent side of a zone cut are an authoritative delegation, but are normally not treated as authoritative data.  In general, a referral is a way for a server to send an answer saying that the server does not know the answer, but knows where the query should be directed in order to get an answer.  Historically, many authoritative servers answered with a referral to the root zone when queried for a name for which they were not authoritative, but this practice has declined. </del> 5.

Discussion:
In May, 2015, Tony Finch noted that the definition of "referral" in the current draft at the time was not good. He said: It would be good to review the current definition and make improvements if necessary.
Fixed with PR
Change:
If Observe is supported, insert the following step between step 2 and 3 of prot-res: <del> A.  If the request was a registration, encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4. </del> <ins> A.  If the response is an observe notification: If the response is the first notification: compute the AEAD nonce as described in nonce: Either use the nonce from the request, or Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. Then go to 4. If the response is not the first notification: encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4. </ins> 8.4.

Discussion:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
3.1. <del> The "RateLimit-Limit" response field indicates the "request-quota" </del> <ins> The "RateLimit-Limit" response field indicates the "service-limit" </ins> associated to the client in the current "time-window". If the client exceeds that limit, it MAY not be served. The field value is <del> The "expiring-limit" value MUST be set to the "request-quota" that is </del> <ins> The "expiring-limit" value MUST be set to the "service-limit" that is </ins> closer to reach its limit. The "quota-policy" is defined in quota-policy, and its values are

Discussion:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.
Change:
additional protocol or interface is required. In establishing the DTLS association between endpoints and the Key <del> Distributor, the endpoint acts as the DTLS client and the Key Distributor acts as the DTLS server.  The Key Encryption Key (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT I-D.ietf- perc-srtp-ekt-diet via the EKTKey message. </del> <ins> Distributor, the endpoint MUST act as the DTLS client and the Key Distributor MUST act as the DTLS server.  The Key Encryption Key (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT I- D.ietf-perc-srtp-ekt-diet via the EKTKey message. </ins> Note that following DTLS-SRTP procedures for the I-D.ietf-perc-double cipher, the endpoint will generate both E2E and HBH encryption keys and salt values.  Endpoints MAY use the DTLS-SRTP generated E2E key <del> or MAY generate different E2E keys.  In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Distributor via the EKTKey message.  That is because every endpoint in the conference uses the same SRTP master salt.  The endpoint only transmits the SRTP master key (not the salt) used for E2E encryption to other endpoints in RTP/RTCP packets per I- D.ietf-perc-srtp-ekt-diet. </del> <ins> for transmission or MAY generate a fresh E2E key.  In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Distributor via the EKTKey message.  That is because every endpoint in the conference uses the same SRTP master salt.  The endpoint only transmits the SRTP master key (not the salt) used for E2E encryption to other endpoints in RTP/ RTCP packets per I-D.ietf-perc-srtp-ekt-diet. </ins> Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media Distributor to establish the HBH key for transmitting RTP and RTCP

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.