jiebi/CodeConvo huggingface dataset:
Code change:
ordered delivery of cryptographic handshake data start from zero in each packet number space. <ins> fig-hs shows a simplied handshake and the exchange of packets and frames that are used to advance the handshake.  Exchange of application data during the handshake is enabled where possible, shown with a '*'.  Once completed, endpoints are able to exchange application data. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol that is in use.

Related discussion:
text: This does a little shuffling to move some of the context-setting up. It then adds some more meat to the introductory section.
Thanks for the review Jana. I've taken most of this, with small tweaks only. Two things I didn't take: Interleaving explanation with references to sections sounded appealing, but it turns out to be both harder to read as the links break up the flow, and harder to scan for links (the structure section serves as an abbreviated and accessible ToC). I didn't move the connection piece below streams as I think that - at this level - talking about the connection is important context. I've moved the picture to the section, which didn't have that simple diagram (just some more complex ones), and I think benefits from it.
When I was reading quic-transport I found it very difficult to deal with the forward references. Streams are presented before connections, the overall state machine isn't introduced up front, packets come long after frames, and both are long before the wire formats are described. It might worth revisiting the section ordering.
At some point, transport was hugely restructured, and I believe many of those changes were good, but some didn't work out that well. I find streams coming before connections particularly odd.
The larger idea is "high-level concepts, then wire encoding" which I think makes sense. It puts the things that someone needs for a conceptual understanding of the protocol in one place, and the things that someone needs to implement the protocol elsewhere. Within the high-level concepts, I also find it strange that connections don't come before streams. However, the "connections" group also includes things that really don't deserve pride-of-place as the first couple things to be discussed, either.
I think that the main concept you need is that QUIC has a connection that is shared state between two endpoints. The later sections about connections go into more detail than you need to understand the stream sections. But I note that we don't properly provide that basic knowledge in our introductory parts, which are quite lean. Leanness is good, but we might have overdone it slightly in this regard.
Having worked my way through the spec, my suggested resolution to this is that Section 5.3 needs to be earlier, perhaps much earlier. At the least, it should open Section 5; some or all of it might belong in Section 1.
Thanks for working through this!
Code change:
3. <del> A Working Group Chairs are responsible for determining how to best </del> <ins> Working Group Chairs are responsible for determining how to best </ins> accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if <del> a the proposed policy and use is acceptable. </del> <ins> the proposed policy and use is acceptable. </ins> <del> Chairs MUST involve Area Directors any decision to use GitHub for anything more than managing of drafts. </del> <ins> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </ins> While a document editor can still use GitHub independently for documents that they edit, even if the working group does not

Related discussion:
text: A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara
Code change:
the "challenges" dictionary. The client sends these updates back to the server in the form of a <del> JSON object with the response fields required by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </del> <ins> JSON object with contents as specified by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </ins> For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: The server updates the authorization document by updating its <del> representation of the challenge with the response fields provided by </del> <ins> representation of the challenge with the response object provided by </ins> the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 (OK) response with the updated challenge

Related discussion:
text: Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.
Code change:
higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. <del> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> A Stopped Event occurs after the Listener has stopped listening.

Related discussion:
text: In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!
Code change:
For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the connection ID sequence number is "3", and the packet number is <del> "aead", the nonce will be set to "6b2611489cba2b63a9a873e2". </del> <ins> "aead", the nonce will be set to "6b2611489cba2b63a9e873e2". </ins> 6.3.2.

Related discussion:
text: The draft states that Shouldn't be the result 6b2611489cba2b63a9e873e2 instead of 6b2611489cba2b63a9a873e2?
Yes, I submitted PR for this issue.
Code change:
suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I- <del> D.sandj-tls-iana-registry-updates has been applied.]] </del> <ins> D.ietf-tls-iana-registry-updates has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.

Related discussion:
text: draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.
Code change:
calculation of the counter signature can be computed.  Details on computing counter signatures are found in counter_signature. <del> This parameter provides the time the content was created.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content was created. The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970. </del> <ins> This parameter provides the time the content cryptographic operation is performed.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content structure was created.  The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970.  The field is primarily intended to be to be used for countersignatures, however it can additionally be used for replay detection as well. </ins> The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional

Related discussion:
text: It makes sense that we do not talk about creation time of the content. However the concept of having a time in the header is also very reasonable for things like countersignatures where one wants to make a timestamp as there is no content that the time marker can be placed in. We therefore change the text to make the time field be the time that the cryptographic operation was performed at.
Code change:
guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. <del> Conversely, the application programmer MUST recognize that the JS </del> <ins> Conversely, the application programmer needs to be aware that the JS </ins> does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected

Related discussion:
text: In the last paragraph of section 8 at "programmer MUST recognize". That is not an appropriate use of 2119. I suggest "needs to be aware" instead of "MUST recognize".
This seems right
Code change:
The header value is <del> The delta-seconds format is used because: </del> <ins> The delay-seconds format is used because: </ins> it does not rely on clock synchronization and is resilient to clock adjustment and clock skew between client and server (see <del> SEMANTICS Section 4.1.1.1); </del> <ins> Section 5.6.7 of SEMANTICS); </ins> it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.

Related discussion:
text: uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...
Code change:
Distributor, this framework utilizes a DTLS-SRTP RFC5764 association between an endpoint and the Key Distributor.  To establish this association, an endpoint will send DTLS-SRTP messages to the Media <del> Distributor which will then forward them to the Media Distributor as </del> <ins> Distributor which will then forward them to the Key Distributor as </ins> defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKT Key) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I-

Related discussion:
text: Replaced Media with Key distributor in on important place. Replaced the DTLS tunnel with TLS according to the latest tunnel draft. A couple of more wording fixes.
Code change:
session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a <del> result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup.  Note that the final answer itself may be different than any received provisional answers. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack

Related discussion:
text: Originally raised by Christer Section 3.2 says: "JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known." 1) I would like explicit text saying that this is a deviation from RFC 3264, where there is no such thing as a provisional answer. I would like to have a dedicated ³Deviations to RFC3264² (or something similar) section. 2) I would like explicit text saying that the final answer may be completely different (in terms of candidates, codecs, accepted m- line etc) from the provisional answer. 3) Related to 2), the final answer may also require NEW resources to be allocated.
We discussed this and we don't think text is needed for 1) or 3); the offerer doesn't release resources until the final answer. For 2), what kind of text did you have in mind?
Few notes to cullen from talking wtih Christer Christer proposals ... adding section "SDP Offer/Nswer Usage" document variation we make on SAVPF stuff explain how ANSWE / PR answer are used withen paringin multiple to single offer Points to section for details ... follwo proccedures in 3264
Cullen, I think I improved this. PTAL
Code change:
Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/631. <del> 3.6. </del> <ins> 3.7. </ins> All QUIC packets carry packet numbers in cleartext, and while the protocol allows packet numbers to be skipped, skipping is not

Related discussion:
text: Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.
Code change:
authorities). Servers which are authenticating with a PSK MUST NOT send the <del> CertificateRequest message. </del> <ins> CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). </ins> 4.3.2.1.

Related discussion:
text: When we banned client auth and PSK, we only meant to do it for the main handshake, not the post-handshake phase. This reverts that change, as well as clarifies the prophibition on PSK plus cert-based auth.
Code change:
8.1. <del> An Endpoint (name, sector) pair is unique within the et of endpoints </del> <ins> An Endpoint (name, sector) pair is unique within the set of endpoints </ins> registered by the RD.  An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint.

Related discussion:
text: All expected to be uncontroversial; to be merged soon.
Commit 3809be46013e9708a6584c4fb730e7cfecab5f22 should have been part of this as well, and is already applied to master.
Code change:
12.1. <del> Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. </del> <ins> Implementers need to pay close attention to the protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because an attacker can forge Evidence or manipulate the Attesting Environment.  For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, by isolating the two environments from each other in some way. </ins> Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to

Related discussion:
text: Signed-off-by: Dave Thaler
` Isolate? From what? “Isolation” seems to be used several times in this and later sections without saying who’s isolating what from whom.
I don't understand that sentence either. Propose removing it. Another sentence: Propose removing "isolation and" Other uses of isolation I think are fine, where it means that an Attesting Environment cannot be modified by a Target Environment it measures. Any way of protecting that might be called "isolating" the two environments from each other in some way.
Code change:
group.  Initialization keys are published for each client (ClientInitKey). <del> A secret that represent a member's contribution to the group </del> <ins> A secret that represents a member's contribution to the group </ins> secret (so called because the members' leaf keys are the leaves in the group's ratchet tree).

Related discussion:
text: Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Code change:
recommendation to use stronger language deprecating use of both SHA-1 and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been <del> deprecated.. </del> <ins> deprecated. </ins> Section 4.3:

Related discussion:
text: NAME thanks, updated with the additional changes.
NAME NAME NAME Feel free to merge when you get a chance
Great! Now on to Daniel's comments.
Code change:
10. <ins> This section discusses various operational and deployment considerations. 10.1. </ins> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying proxy services that are on path between clients and servers avoids adding

Related discussion:
text: This makes the choice of a 1:1 mapping clear: avoid being used as an open proxy through explicit configuration of your ACLs. cc NAME
The proxy has a fixed mapping. It's resource maps to just one request resource. That's a deliberate choice that we should probably be much more up front about.
Yes, I think this makes sense, but it took me a while to realize it when implementing. Having a section on mapping state on the proxy would be useful.
Vittorio says: This relates in particular to the potential for generic services with open destination (not a capability in the proposal) to be used for nefarious purposes (spamming, bot net command and control, hiding illegal activity, etc...).