jiebi/CodeConvo huggingface dataset:
Code change:
This property specifies that a message should be sent in such a way that the transport protocol ensures all data is received on the other side without corruption.  Changing the 'Reliable Data Transfer' <del> property on Messages is only possible if the transport protocol supports partial reliability (see prop-partially-reliable). Therefore, for protocols that always transfer data reliably, this property is always true and for protocols that always transfer data unreliably, this property is always false.  Changing it may generate an error. </del> <ins> property on Messages is only possible if the Connection supports reliability.  When this is not the case, changing it will generate an error. </ins> 7.3.8.

Related discussion:
text: I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.
Code change:
Specific processing MUST also be applied for the following attribute lines: <del> If present, a single "a=ice-lite" line is parsed as specified in RFC5245, Section 15.3, and a value indicating the presence of ice- lite is stored. </del> If present, a single "a=ice-ufrag" line is parsed as specified in RFC5245, Section 15.4, and the ufrag value is stored.

Related discussion:
text: LGTM
http://rtcweb-URL mentions its use at media level; this should be clarified.
Code change:
process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> When an operator deploys a current HTTPS server, it generally prompts him to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </del> <ins> When deploying a current HTTPS server, an operator generally gets a prompt to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </ins> The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.

Related discussion:
text: Avoid changing the "him" in the MitM paragraph, because of the inherent notion of a Man in the Middle, which is a larger discussion.
LGTM. Thanks for the elegant fix.
Code change:
16.3. This registry lists identifiers for types of credentials that can be <del> used for authentication in the MLS protocol.  The extension type field is two bytes wide, so valid extension type values are in the </del> <ins> used for authentication in the MLS protocol.  The credential type field is two bytes wide, so valid credential type values are in the </ins> range 0x0000 to 0xffff. Template:

Related discussion:
text: I noticed a bunch of typos in the "IANA Considerations" section: the "ciphersuites" and "credentials" were probably copy-pasted from the "extension" one, and some parts were not changed correctly. This PR fixes these typos.
Discussed 20210526 Interim: editorial will be taken up by editors.
Thanks!
Code change:
entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at <del> either endpoint. </del> <ins> either endpoint.  The AEAD also protects Initial packets against accidental modification. </ins> All other packets are protected with keys derived from the cryptographic handshake.  The cryptographic handshake ensures that

Related discussion:
text: The description neglected to mention this. Obviously, the confidentiality protection (specifically, the lack thereof) is the part that needs to be highlighted, but we shouldn't neglect the other purpose of using an AEAD here.
Code change:
transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. <ins> Note that while setDirection sets the direction attribute of the transceiver immediately (sec.transceiver-direction), this attribute does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive.  The direction in effect is represented by the currentDirection attribute, which is only updated when an answer is applied. </ins> 4.2.4. The direction method returns the last value passed into setDirection.

Related discussion:
text: Fixes issue .
Section 4.2.3: The setDirection method sets the direction of a transceiver, which affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. [BA] "sets the direction of a transceiver" is a bit confusing because setDirection() doesn't immediately change whether an RtpSender can send or an RtpReceiver can receive. Since setDirection does immediately change the value of the transceiver.direction attribute you might say "sets the transceiver.direction attribute" instead. Also, an application may want to determine the current direction (e.g. whether an RtpSender can send or an RtpReceiver can receive) as opposed to the pending direction (provided by transceiver.direction). Taylor agreed to create a WebRTC 1.0 PR to add the concept of current direction (e.g. by adding a currentDirection attribute). It would therefore be useful to add some text to Section 4.2.3 explaining the distinction. For example: "Note that while setDirection sets the transceiver.direction attribute immediately, this pending direction does not immediately affect whether an RtpSender will send or RtpReceiver will receive. After calls to setLocal/setRemoteDescription, the direction currently in effect is represented by transceiver.currentDirection (the attribute Taylor will be defining)."
As for naming: which of these makes the most sense? "direction"/"currentDirection" "pendingDirection"/"currentDirection" "preferredDirection"/"currentDirection" "preferredDirection"/"negotiatedDirection" I like "preferredDirection" (or something of that nature); "pending" is a bit of a misnomer here because it's possible the set direction may never end up negotiated.
NAME My personal preference would be "direction"/"currentDirection". While "pendingDirection" might be more accurate than "direction", I'm a bit scared of all the spec changes that might be result from changing the attribute name.
Agree with NAME
LGTM (direction + currentDirection).
NAME can this now be closed?
I don't think Bernard's concern was addressed, which is that "sets the direction of a transceiver" is too ambiguous. Now that we have a "currentDirection" to reference, I'll add some clarifying text like he suggested.
Resolved by .
Code change:
blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document I-D.ietf-privacypass-architecture. </del> <ins> Architecture document ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This

Related discussion:
text: There are two cases where the term seems to be used with importance. I suspect that the Internet isn't actually that important in the context / scope of this protocol document, especially since the architecture document doesn't mention it.
Yep, good catch. It's not.
Is there a more polite way to phrase this disclaimer?
This follows RFC 2119 (URL) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents. Though technically these should probably be "SHOULD NOT" and "SHALL NOT" to be in line with the RFC terms.
What requirements are being defined in the quoted text though? Is it simply a statement of fact like "this document doesn't cover architectural stuff" or is it "implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document"?
NAME this is just a statement of fact -- we don't need to shout it =)
Code change:
If the m= section proto value indicates use of RTP: <del> If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer), find one and associate it with this m= section according to the following steps: </del> <ins> If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps.  Note that this situation will only occur when applying an offer. </ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section

Related discussion:
text: Fixes URL
See comment in
Alright, try this version
Section 5.8 contains the sentence: "If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer)..." -- it is grammatically ambiguous whether this says that the absence of an RtpTranceiver can only happen with an offer, or if the presence of an RtpTranceiver can only happen with an offer. Suggest rephrasing as: "If applying an offer and there is no RtpTransceiver associated with this m= section, find one..."
NAME can you take a look at this?
I'm not sold on this approach, since it then invites the question, what should one do if this condition happens when applying an answer? My suggestion would be to still call this out explicitly, but try to avoid the ambiguity noted above by changing the parenthetical to its own sentence at the end of the paragraph, e.g. "Note that this situation will only occur when applying an offer."
I changed it to that.
LGTM
Code change:
"lazy" version of this operation, where only the leaf changes and intermediate nodes are blanked out. <del> The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if the proposals vector is empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for validating a Commit is as follows: </del> <ins> By default, the "path" field of a Commit MUST be populated.  The "path" field MAY be omitted if (a) it covers at least one proposal and (b) none proposals covered by the Commit are of "path required" types.  A proposal type requires a path if it cannot change the group membership in a way that requires the forward secrecy and post- compromise security guarantees that an UpdatePath provides.  The only proposal types defined in this document that do not require a path are: "add" "psk" "app_ack" "reinit" New proposal types MUST state whether they require a path.  If any instance of a proposal type requires a path, then the proposal type requires a path.  This attribute of a proposal type is reflected in the "Path Required" field of the proposal type registry defined in mls-proposal-types. Update and Remove proposals are the clearest examples of proposals that require a path.  An UpdatePath is required to evict the removed member or the old appearance of the updated member. In pseudocode, the logic for validating the "path" field of a Commit is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:

Related discussion:
text: This PR introduces a notion of a proposal type being "path safe", in the sense that it is safe for the path to be omitted. (Better phrasing welcome!) The field is required default, and allowed to be omitted only if all the proposals in the Commit are path-safe.
Thanks for taking care of this fix! One suggestion: Instead of having a global list of which types are path safe and which ones aren't, we could make it a property of the proposal. Maybe something like this: Regarding the name, the only thing I can think of is that we could invert the property and call it : In fact, I think I'd be slightly in favor of the latter proposal.
Discussion on virtual interim: OK to keep using type TODO(NAME "path safe" -> "path required" Otherwise clear to merge
The authoritative definition (in Section ) of when to include a is not the same as the summary below. For example, if an implementation adds a custom proposal type, according to the summary, a path is required, whereas according to the definition above it, no path is required. Ultimately, it depends on the nature of the proposal and the desired security guarantees if a path is required. However, I think the safer option is to require a path by default and maybe leave it to the definition of the respective custom proposal to explicitly specify if a path is not required.
Code change:
The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP, and below) don't cause <del> packets for a QUIC connection to be delivered to the wrong endpoint. The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </del> <ins> packets for a QUIC connection to be delivered to the wrong QUIC endpoint.  The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </ins> The connection ID is chosen by each endpoint using version-specific methods.  Packets for the same QUIC connection might use different

Related discussion:
text: Editorial NiTs when reviewing the invariant text. These NiTs address readability issues, and do not intend to change the meaning of the text.
Is there an associated issue?
Thanks Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn't seem to be any statement of bit order saying. Is it worth declaring network byte/bit order earlier in section 4? This also clarifies the placement of fields within a byte, which was basically assumed knowledge otherwise. 3) Personally, I don't think: "The length of the Destination Connection ID is not specified" is a great choice of words. Surely, this needs to be specified somewhere for a protocol instance to use it? This reads better as something like: The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification. 4) The brackets here seem to point to connection IDs in general, not the DCID "(see Section 5.3)". Is it worth writing that as "Connection IDs are described in Section 5", rather than use brackets? The same is true for versions. 5) In section 5.3: "the wrong endpoint" is taken as the wrong transport endpoint, but some of our IP and subIP colleagues would use the term endpoint for other uses, so one insertion of "transport" would perhaps help? 6) In the appendix A, this: "QUIC forbids acknowledgments of packets" - still has me wondering what is actually intended to be understood, because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment (it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I'm not sure what to say here I think the combination of not... forbids threw me off the meaning. Changes proposed in
Thanks for changing SCID/DCID to "Source Connection ID" and "Destination Connection ID", that seems like a good change.
Code change:
protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. <del> Specifically, a Transport System would consider protocols </del> <ins> Specifically, a Transport Services system would consider protocols </ins> identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS

Related discussion:
text: Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!
Code change:
2. <del> To start a request, the client instance sends RFC8259 document with </del> <ins> To start a request, the client instance sends a RFC8259 document with </ins> an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by <del> extensions to this protocol as described in </del> <ins> extensions to this protocol as described in request-extending. </ins> A non-normative example of a grant request is below:

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:
Code change:
12.34. <ins> GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol.  This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features. First, in many applications, the return of a subject information to the client instance could indicate to the client instance that the end-user is the party represented by that information, functionally allowing the end-user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to be requesting information about the end user.  This is facilitated by the several interaction-start defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end-user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user.  Confusing these states could lead to an attacker having their account associated with a privileged user.  Client instances can mitigate this by having distinct code paths for primary end user authentication and requesting subject information about secondary users, such as in a call center.  In such use cases, the client software used by the resource owner (the caller) and the end-user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request. Second, RO's interacting asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization.  As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time.  This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request.  An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access.  To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure the RO can clearly make the appropriate security decision.  Furthermore, audit capability, and the ability to undo access decisions that may be ongoing, is particularly important in the asynchronous case. </ins> An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of

Related discussion:
text: Fine ;-) (on my side, I always tend to consider CIBA as some degenerate phishing experiment, but maybe that's too extreme)
Code change:
Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS </del> <ins> Replace the IP address of the ICE candidate with its mDNS </ins> hostname, and expose the candidate as usual. An ICE agent can implement this procedure in any way so long as it

Related discussion:
text: PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?
Code change:
shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

Related discussion:
text: Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though.