jiebi/CodeConvo huggingface dataset:
Change:
2.2. <del> Here we discuss candidate mechanisms for provisioning the User Equipment with the Captive Portal API URI to query captive portal state and navigate the portal. </del> <ins> The Provisioning Service is primarily responsible for providing a Captive Portal API URI to the User Equipment when it connects to the network, and later if the URI changes.  The provisioning service could also be the same service which is responsible for provisioning the User Equipment for access to the Captive Network (e.g., by providing it with an IP address).  This section discusses two mechanisms which may be used to provide the Captive Portal API URI to the User Equipment. </ins> 2.2.1.

Discussion:
We didn't really lay out the role of the provisioning service. While we still don't have any requirements on it, this changes the provisioning service section to give more guidance about its role in the network.
Any thoughts on whether we should expand to add some requirements? E.g. URI scheme MUST be HTTPS.
Roman writes, "The Provisioning Service is primarily responsible for providing a portal URI to the User Equipment when it connects to the network, and later if the URI changes. The provisioning service could also be the same service which is responsible for provisioning the User Equipment for access to the Captive Network (e.g. by providing it with an IP address). This section discusses two mechanisms which may be used to provide the portal URI to the User Equipment. It is expected that the provided URI will be for the API described in Section 2.3".
Change:
"A DNS server that implements DNS over TLS RFC7858 and may optionally implement DNS over DTLS RFC8094."  (Quoted from <del> RFC8310, Section 2) </del> <ins> RFC8310, Section 2) Other types of DNS servers might also be considerd privacy-enabling, such as those running DNS over HTTPS I-D.ietf-doh-dns-over-https. </ins> 7.

Discussion:
I like the additional wording. I'll add it and take the question to the chairs to take to the WG.
Good catch on "DNS over TLS" -> "DNS over HTTPS". I didn't go with "DNS Queries over HTTPS" because it doesn't really describe the protocol.
Simple mistake: "DNS over TLS" should be "DNS over HTTPS" at line 1040. Or "DNS Queries over HTTPS" may be better because it is a draft name.If we're going to add class here, then I think (1) we need to go back to the WG and (2) we need to add something: "In practice, the class for nearly every query is IN. There are some queries for CH, but they are usually for the purposes of information about the server itself rather than for a different type of address" I wrote a doc some time ago attempting to deprecate class, because of the way it keeps popping up as though it is viable.
Change:
Clients MAY include versions following the pattern "0x?a?a?a?a" in their "Compatible Version" list, and the server in their "Supported Version" list.  Those versions are reserved to exercise version <del> negotiation (see the Versions section of QUIC), and MUST be ignored </del> <ins> negotiation (see the Versions section of QUIC), and will be ignored </ins> when parsing these fields.  On the other hand, the "Received Negotiation Version" list MUST be identical to the received Version Negotiation packet, so clients MUST NOT add or remove reserved

Discussion:
This construction directly undermines greasing by privileging the handling of greased versions. Please don't do this. As I alluded to in , this doesn't need to match the Version Negotiation packet/datagram contents. What is important here is that the list doesn't include a version that the client would have preferred to attempt over the current one. If you validate the server values that way, then you never have to worry about greased versions being different in the two different places. Indeed, you can have the server offer Version Negotiation packets that include more versions than they claim in their handshake (this being beneficial during the rollout of a fancy new version of the protocol).
Can you elaborate on how this undermines greasing? All we say is that you can add grease to version lists, but the Received Negotiation Version list needs to be transmitted as an opaque blob. We don't treat greased versions differently on receipt anywhere.
Well, the second MUST NOT pertains to something that I think should be removed. But you say "[reserved versions] MUST be ignored when parsing these fields". That tells implementations to train themselves to recognize greased versions. At that point, they are no longer treating these as versions that they just don't understand, but something special. The whole point of using an odd pattern was to ensure that this never happened.
Fair enough, if we replaced with: Would that be OK?
That's all I'm asking for. (Along with striking the echo of the VN packet, but we'll pursue that separately. The requirement there is reasonable if you assume that echoing the bits is necessary.)
Change:
The client then creates a PaddedServerNameList: <ins> The true SNI. A random 16-octet value to be echoed by the server in the "encrypted_server_name" extension. Zero padding whose length makes the serialized struct length match ESNIKeys.padded_length. </ins> This value consists of the serialized ServerNameList from the "server_name" extension, padded with enough zeroes to make the total structure ESNIKeys.padded_length bytes long.  The purpose of the

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes valid at session level. </del> Once all the session-level lines have been parsed, processing continues with the lines in media sections.

Discussion:
Not ready yet.
LGTM with editorial comment as above.
Please apply same presence/absence treatment for all
http://rtcweb-URL [TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level.]
(session-level, specifically)
Change:
In this model, an Attester conveys Evidence to a Verifier, which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result which the Attester treats as <del> opaque data.  The Attester does not consume the Attestation Result, but might cache it.  The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. </del> <ins> opaque data. The Attester does not consume the Attestation Result, but might cache it.  The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy.  The Attester may also present the same Attestation Result to other Relying Parties. </ins> Three ways in which the process may fail include:

Discussion:
related to There is something foundational I am not following about this section. The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1. I'm not sure how to reconcile this discrepancy. Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4. [restated here but same feedback on -13] -- Figure 5. Shows the Attester consuming Attestation Results -- Figure 5. Shows the Attester producing Attestation Results -- Figure 6: Shows Relying party consuming Evidence -- Figure 6: Shows the Relying Party producing/passing Evidence The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns." I don't follow what is being illustrated in the context of RATS. What is the takeaway for implementers or designers from this section? [Author's response] URL [Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.
Reply by email: "The Attester does not consume the Attestation Result, but might cache it. "
The text explains the intent correctly regardless of how the lines are drawn. I can convince myself that it is correct draw the line through the box (or not). The important clarifying point should be that the end-to-end message flow as described in the conceptual architecture is preserved through the various topology models that may exist. Second point is there can be a large variety of topology models (aka hybrids) but none of these hybrids changes the expectation of end-to-end message flow.
also helps.
Change:
RtpTransceiver. If no RtpTransceiver was found in the previous step, create <del> one with an inactive RtpSender and active RtpReceiver. </del> <ins> one with a recvonly direction. </ins> Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid

Discussion:
Reference transceiver direction as opposed to "active" senders/receivers We initially thought there would be an "active" bit on senders/receivers to control the direction of a media description, but instead we now have a "setDirection" API on the transceiver. So we should reference that.
lgtm
Change:
In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type <del> and length fields. </del> <ins> and length fields, but not including record layer headers. </ins> 4.4.1.

Discussion:
When I was implementing the key schedule, it was unclear to me what stands for. This additional note would help other implementors. Kazuho Oku pointed out the similarity to Handshake Context. So, I updated that part, too.
Change:
Secrets may be baked into or hardware or software device components, such as secure enclaves. <ins> Where secrets are baked into hardware at manufacturing time, the secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import into a server. </ins> 6.2. PSK provisioning systems are often constrained in application-

Discussion:
Notes: Certificateless server-to-server communication is definitively used for OTT communications e.g. URL
Change:
corresponding to the token labels chosen by the client instance in the request-token-multiple. <del> In this non-normative example, two bearer tokens are issued under the names "token1" and "token2", and only the first token has a management URL associated with it. </del> <ins> In this non-normative example, two tokens are issued under the names "token1" and "token2", and only the first token has a management URL associated with it. </ins> Each access token corresponds to one of the objects in the "access_token" array of the client instance's request-token-multiple.

Discussion:
…alue should be the boolean false. Please, correct me if I wrong.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 23bd329e9c764cedfe6a8dd1e26b557aa8fda9a6 https://deploy-preview-209--gnap-core-protocol-editors-URL
Ok, I will take care of it a bit later. I also suggest omitting from other examples as it's a default value.
Done.
We'll need to add an example of in at least one location, but otherwise these changes are good.
Done in URL
The intent was to make the examples bound tokens by default, so instead of changing the examples, any text surrounding these examples referring them as bearer needs to be adjusted appropriately.
Change:
7. <ins> Add a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls- rfc4492bis, which is standards track, are not marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS I-D.ietf-tls-tls13.  A Standards Track document RFC5226 is required to register an entry with the value "Yes". 8. </ins> IANA is to update the TLS ClientCertificateType Identifiers registry as follows:

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
contains the value of the key. <del> This key structure contains only private key information; care must be taken that it is never transmitted accidentally.  For public keys, there are no required fields.  For private keys, it is REQUIRED that </del> <ins> This key structure does not have a form which contains only public members.  As it is expected that this key structure is going to be transmitted, care must be taking that it is never transmitted accidentally or insecurely.  For symmetric keys, it is REQUIRED that </ins> 'k' be present in the structure. 14.

Discussion:
This is basically the text that Ludwig agreed to. Will seek second confirmation for issue
In Section 13.2. there is the following text: "This key structure contains only private key information, care must be taken that it is never transmitted accidentally. For public keys, there are no required fields. For private keys, it is REQUIRED that 'k' be present in the structure." This should probably read something like this: "This key structure only contains secret (or symmetric) key information, care must be taken that it is never transmitted accidentally. For symmetric keys, it is REQUIRED that 'k' be present in the structure."
What if we change it to be This key structure does not have a form that contains only public members. For symmetric keys, it is REQUIRED that 'k' be present in the structure.
I really have nothing against the "care must be taken ..." part. I'd actually tend to leave it in, but feel free to rephrase that as you see fit.
Change:
validate the client's IP address before parsing the client's first flight.  This impacts compatible version negotiation because a server who wishes to send a retry packet before parsing the client's first <del> flight won't have parsed the client's handshake version information yet.  If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version </del> <ins> flight won't have parsed the client's Version Information yet.  If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version </ins> negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both.  For example, that could be accomplished by having the server send a retry packet first and

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.
Change:
Result to the Relying Party is current, while a previous handle was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results <del> may only be as fresh as the previous epoch. </del> <ins> may only be as fresh as the previous epoch.  If the Relying Party remembers the previous handle H during an epoch window as discussed in epochfreshness, and the message is received during that window, the Attestation Result is accepted as fresh, and otherwise it is rejected as stale. </ins> 16.4.

Discussion:
Biggest bug in the last pull request is that the diagram had the attester sending a different Attestation Result than the one the Verifier gave it, which would invalidate the signature. Second issue was that the lines didn't line up. Third issue was that it was missing the tie to the "epoch window" discussion in {{epochfreshness}} to explain how the Relying Party deals with the mismatched handles that the example diagram has. Signed-off-by: Dave Thaler
The appendix on Handles needs some work to better clarify the concepts and simplify the flow. Some things about the text: Clearly define what is a handle; Explain its relation with epoch establishment; Clarify network jitter impact on handle validity; Explain what are the base rules for working with handles; Some further points on the sequence diagram: Fix confusing legend; Add some accompanying prose to explain the depicted use case as it's not self-evident;
Thanks for aligning the diagram, I knew I had forgotten something. The changes look good to me.Ship it!
Change:
7. <del> The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet- mpls.  Encryption may provided within the TSN network using MACSec IEEE802.1AE-2018. </del> <ins> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in I-D.ietf-detnet-architecture.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet-mpls.  The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network.  Application flows can be protected through whatever means is provided by the underlying technology.  For example, encryption may be used, such as that provided by IPSec RFC4301 for IP flows and/or by an underlying sub-net using MACSec IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows. </ins> 8.

Discussion:
Work In progress - Wanted to get the figure changes out for review. Need to check if the overly wording is complete. There was a lot of inter working text - I have commented out.
Change:
5. <ins> [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published.] Trickle ICE I-D.ietf-ice-trickle considers a similar problem, namely whether an ICE agent should allow a checklist to enter the Failed state if more candidates might still be provided by the remote peer. The solution, specified in I-D.ietf-ice-trickle, Section 8, is to wait until an end-of-candidates indication has been received before determining ICE failure. However, for the same reasons described above, the ICE agent may discover peer-reflexive candidates after it has received the end-of- candidates indication, and so the solution proposed by this document MUST still be used even when the ICE agent is using Trickle ICE. Note also that sending an end-of-candidates indication is only a SHOULD-strength requirement, which means that ICE agents will need to implement an backup mechanism to decide when all candidates have been received, typically a timer.  Accordingly, ICE agents MAY use the PAC timer to also serve as an end-of-candidates fallback. 6. </ins> The security considerations for ICE are defined in RFC8445.  This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations. <del> 6. </del> <ins> 7. </ins> This specification makes no requests to IANA.

Discussion:
See URL for details.
Looks good. It's probably good to also add a note, asking the RFC Editor to replace XXX with the Trickle RFC number, once published. Something like: [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of once it has been published.]
Change:
which includes, but not limited to, having no access to RTP media unencrypted and having limits on what RTP header field it can alter. <del> Key Distributor: An entity that is a logical function which passes keying material and related information to endpoints and Media Distributor(s) that is appropriate for each.  The Key Distributor might be co-resident with another entity trusted with E2E keying material. </del> <ins> Key Distributor: An entity that is a logical function which distributes keying material and related information to trusted endpoints and Media Distributor(s), only that which is appropriate for each.  The Key Distributor might be co-resident with another entity trusted with E2E keying material. </ins> Conference: Two or more participants communicating via trusted endpoints to exchange RTP flows through one or more Media Distributor. <ins> Call Processing: All tusted endpoints in the conference connect to it by a call processing dialog, such as with the Focus defined in the Framework for Conferencing with SIP RFC4353. </ins> Third Party: Any entity that is not an Endpoint, Media Distributor, Key Distributor or Call Processing entity as described in this document.

Discussion:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.
Change:
2.2.2. <del> Although still a work in progress, I-D.ietf-intarea-provisioning- domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </del> <ins> I-D.ietf-intarea-provisioning-domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </ins> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the

Discussion:
PvD is almost certainly going to be published first, so remove the lead-in to it in preparation for integrating the full rfc soon.
When the document says: It might be better to just remove the lead-in part, since it appears PvD will be published ahead of this document.