jiebi/CodeConvo huggingface dataset:
Change:
JSONPath query, e.g., because of resource depletion, but this is not modeled in the present specification.) <del> Discussion (D1): are we ready for the error model defined here, i.e. one that does not have runtime errors, but only compile time errors? </del> 3.2. In this specification, the semantics of a JSONPath query are defined

Discussion:
Here's a chance to actually have the discussion if anyone wants to.
Well, I'm certainly ready for this model.
I'm good with the approach described in the text. As long as a string can be parsed as a Path, it should evaluate. I can't see a case where processing a valid path against a value would produce an error; merely empty result sets. This means that the only errors should be syntax errors, correct?
I think so.
May I encourage reviewers who are in favour of this PR to approve it?
I was awaiting a bit more discussion.
Ok, I've requested a review from Stefan.
Yes absolutely ... I like that clean concept a lot.
Change:
Server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment. <ins> Many HTTPS implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this can happen.  DNS API servers SHOULD utilize OCSP Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration

Discussion:
In order to prevent a dependency on traditional DNS or a DNS query for CRL/OCSP certificate validation check, OCSP stapling should be used for the HTTPS web server.
we're probably better off describing the potential deadlock in revocation and mentioning stapling as a best practice.. but in general I think we want to stay away from specifying a whole lot of how-to-profile-https details as these things do differ between clients and we tend to accept all of the variants as "https".. for e.g.
Change:
The values "token_input" and "blinded_element" are stored locally and used later as described in private-finalize.  The Client then <del> generates an HTTP POST request to send to the Issuer, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below. </del> <ins> generates an HTTP POST request to send to the Issuer Request URI, with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below. </ins> 5.2.

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
The createOffer method generates a blob of SDP that contains an offer per RFC3264 with the supported configurations for the session, including descriptions of the media added to this PeerConnection, the <del> codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent.  An options </del> <ins> codec, RTP, and RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent.  An options </ins> parameter may be supplied to provide additional control over the generated offer.  This options parameter allows an application to trigger an ICE restart, for the purpose of reestablishing

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.  For example, if the domain name being validated is <del> "example.org", then the client would provision the following DNS </del> <ins> "www.example.org", then the client would provision the following DNS </ins> record: A client responds with an empty object ({}) to acknowledge that the

Discussion:
Since is consistently used to represent the ACME server, we should always use to represent the ACME client. Whenever there's a single hostname we prefer the variant because the prefix makes it easier to quickly distinguish from . When there are two hostnames we use both and . Since we already used one order ID consistently through the doc, I made sure that its identifiers, notBefore, and notAfter were always the same. I tweaked the "expires" so it would be in a reasonable range (not precisely equal to the notBefore). Note that the "pending" version of the order has a slightly different expires than the "valid" order. One version of the finalized order had a cert ID of jWCdfHVGY2M and another had mAt3xBGaobw. Harmonized on mAt3xBGaobw since it was also used in the certificate retrieval example. Also fixed an accidentally duplicated nonce.
:100:
Change:
TODO <ins> 1.1. The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.rescorla- tls-ctls. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
Notes: Certificateless server-to-server communication is definitively used for OTT communications e.g. URL
Change:
The authors thank Lorenzo Colitti for providing the majority of the content for the Captive Portal Signal requirements. <ins> The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server. </ins> The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van

Discussion:
A reviewer requested that we provide more detail on how the user equipment should so certificate validation. This does so.
Do this. Figure out the proper 'name type'.
Ben suggests Let's use this, and attribute it to him in the acknowledgements.
Change:
If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to <del> receive non-square pixels, this cannot be satisfied and the sender MUST NOT transmit the encoding. </del> <ins> receive non-square pixels, this cannot be satisfied and the attribute MUST NOT be used. </ins> If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its

Discussion:
Still LGTM
NAME we have consensus on this from the editor team, but please comment here if you see anything else and I'll take a look.
Thanks, I think it looks good in general. Regarding the "par" question NAME raised the current text promotes some picture over correct picture aspect ratio. Having a bullet that one selects one that has PAR that the sending side supports to send can result in more optimal choice but also may result in a slight increase in blocked video where a stretched video may be shown instead.
Change:
connection protocols like HTTP/2 RFC7540 do not have a notion of which TLS record a given message is a part of. <del> For simplicity, the mechanisms described in this document require a TLS version 1.2 or later. </del> <ins> Exported Authenticators are meant to be used as a building block for application protocols.  Mechanisms such as those required to advertise support and handle authentication errors are not handled at the TLS layer. For simplicity, the mechanisms described in this document require TLS (or DTLS) version 1.2 or later. </ins> 2.

Discussion:
NAME are you happy with the adjusted text? I don't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface.
I think that this is sneaking in a big change with the DTLS thing. I'll try to find the email...
Change:
An RTT sample MUST NOT be generated on receiving an ACK frame that does not newly acknowledge at least one ack-eliciting packet.  A peer <del> does not send an ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is subsequently sent can include an arbitrarily large Ack Delay field.  Ignoring such ACK frames avoids </del> <ins> usually does not send an ACK frame when only non-ack-eliciting packets are received.  Therefore an ACK frame that contains acknowledgements for only non-ack-eliciting packets could include an arbitrarily large Ack Delay value.  Ignoring such ACK frames avoids </ins> complications in subsequent smoothed_rtt and rttvar computations. A sender might generate multiple RTT samples per RTT when multiple

Discussion:
So here is an alternative proposal. However I also wonder why this paragraph is a MUST requirement while the previous statement (avoiding multiple samples of the same packet) is only a SHOULD? I would see it rather the other way around or both MUSTs.
This is a great improvement, thanks. One additional suggestion (for existing text) below.
Change:
MOPex: MOP extension as defined in this document. <ins> Upstream path/direction: Path or direction from the node to the Root in a DAG. Downstream path/direction: Path or direction to the node from the Root in a DAG. </ins> This document uses terminology described in RFC6550.  For the sake of readability all the known relevant terms are repeated in this section. <ins> 1.2. Currently RPL specification does not have a mechanism whereby a node can signal the set of features that are available on its end.  Such a mechanism could help the root to advertise its capabilities and in response also determine some advanced information about the capabilities of the joining nodes.  This document defines Capabilities which could be supported by the nodes and handshaked as part of RPL signaling.  Capabilities are embedded as RPL control message option as defined Section 6.7 of RFC6550 in the base messages of DIO, DAO and DAO-ACK signaling. </ins> 2. Following are the requirements considered for this documents: <del> MOP extension.  Current MOP of 3-bit is fast depleting.  An MOP extension needs to extend the possibility of adding new MOPs in the future. </del> Backwards compatibility.  The new options and new fields in the DIO message should be backward compatible i.e. if there are nodes which support old MOPs they could still operate in their own

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for <del> the Attester's ability to securely generate Evidence, in which case the Endorser's key material is stored in the Verifier's trust anchor store. </del> <ins> the Attester's ability to securely generate Evidence through Endorsements (see endorsements).  Endorsements might describe the ways in which the Attester resists attack, protects secrets and measures Target Environments.  Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be authenticated and used in the Verifier's appraisal process. </ins> In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material

Discussion:
Reworded paragraph following the word 'vouch' to better explain the how Endorsements affect Verifier's trust in the Attester.
`
"... vouch for the Attester's ability to securely generate Evidence by asserting endorsement claims regarding the ways in which attestation keys are protected. Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be included in the Verifier's appraisal."
This proposal is definitely a step into the right direction. We should not overload this, but I think this is appropriately improved.
"attestation keys are protected" is too narrow
See PR
Change:
type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, token-types. Challenges with unsupported token_type values MUST be ignored. <ins> This value determines the structure and semantics of the rest of the structure. </ins> "issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed

Discussion:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.
Change:
authenticator finished key" with "DTLS-OK" and "Recommended" set to "Y" and this document added to the "Reference" column. <ins> 8.3. IANA is requested to add the following entry to the registry for HandshakeType (defined in RFC8446): "client_certificate_request" with "DTLS-OK" and "Recommended" set to "Y" and this document added to the "Reference" column with the following in the "Note" column: "Used in TLS versions prior to 1.3." </ins> 9. The Certificate/Verify/Finished pattern intentionally looks like the

Discussion:
Hmmm maybe it should be "clientcertificaterequest" to match the other values in the Description column.
If ClientCertificateRequest is a new HandshakeType then there needs to be a registry request. If is adopted will need to also request one for ServerCertificateRequest.
Change:
In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to <del> the load balancers. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server are able to identify and discard packets featuring an invalid MAC. </del> <ins> the load balancers.  Guidance on assigning connection IDs is given in QUIC-APPLICABILITY. </ins> 4.4.

Discussion:
-manageablility has guidelines on how to select ConnIDs at a server, which is really more an -applicability thing. This fixes that.
Change:
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the <del> TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites. (see cipher-suites) </del> <ins> TLS_AES_128_GCM_SHA256 GCM cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 GCM and TLS_CHACHA20_POLY1305_SHA256 RFC7539 cipher suites.  (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for

Discussion:
Note that I'm not entirely convinced we need the GCM reference because RFC 5116, which is referenced in B.4 for the suites, includes a reference to it.
ID nits complains of the following unused references: == Unused Reference: 'AES' is defined on line 4147, but no explicit reference was found in the text == Unused Reference: 'GCM' is defined on line 4305, but no explicit reference was found in the text == Unused Reference: 'PKCS6' is defined on line 4339, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 4342, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 4371, but no explicit reference was found in the text == Unused Reference: 'RFC4507' is defined on line 4392, but no explicit reference was found in the text == Unused Reference: 'RFC5054' is defined on line 4401, but no explicit reference was found in the text == Unused Reference: 'RFC5746' is defined on line 4425, but no explicit reference was found in the text == Unused Reference: 'RFC5878' is defined on line 4436, but no explicit reference was found in the text == Unused Reference: 'RFC7366' is defined on line 4479, but no explicit reference was found in the text
Looking at the editor's copy only AES and GCM remain. I think we can safely remove both because those references are picked up but the cipher suite definitions.
Strike that since we're defining some suites we need to include GCM and move it normative. We can drop the AES reference because it's picked up by the GCM reference.
Change:
location of fields used in the version negotiation process is invariant QUIC-INVARIANTS. <del> This document is focused on the protocol as presently defined in QUIC-TRANSPORT and QUIC-TLS.  Non-invariant parts of the wire image as described herein and in those documents cannot be used to identify QUIC as a protocol, and cannot be relied upon to infer behavior of future versions of QUIC. </del> <ins> This document describes only version 1 the QUIC protocol, whose wire image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Note that features of the wire image described herein and in those documents may change in future versions of the protocol, and cannot be used to identify QUIC as a protocol or to infer the behavior of future versions of QUIC. sec-google-version provides non-normative guidance on the identification of QUIC version 1 packets compared to other deployed versions at the date if publication. </ins> 2.1.

Discussion:
It might be the case that this is true for the whole draft and we should just state this at the beginning but better to double-check!
we will leave this issue open to double-check at the end
Change:
8.1. <ins> Each Message may also contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack dependent.  The following metadata values are supported: 8.1.1. When available, Message metadata carries the value of the Explicit Congestion Notification (ECN) field.  This information can be used for logging and debugging purposes, and for building applications which need access to information about the transport internals for their own operation. 8.1.2. In some cases it may be valuable to know whether data was read as part of early data streams.  This is useful if applications need to treat early data separately, e.g., if early data has different security properties than data sent after connection establishment. In the case of TLS 1.3, client early data can be replayed maliciously (see I-D.ietf-tls-tls13).  Thus, receivers may wish to perform additional checks for early data to ensure it is idempotent or not replayed.  If TLS 1.3 is available and the recipient Message was sent as part of early data, the corresponding metadata carries a flag indicating as such.  If early data is enabled, applications should check this metadata field for Messages received during connection establishment and respond accordingly. 8.2. </ins> The application may check a property to determine if a received Message is the Final Message on a Connection.  For any Message that is marked as Final, the application can assume that there will be no

Discussion:
And add an early data metadata value.
I'll dig up relevant discussions from the TLS WG.
See, e.g.: URL
Looks like a good candidate for a read-only recv property…
NAME Aren't all receives read-only?
Looks good - minor nits noted in URL lgtmMuch better I think!
Change:
The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation. <del> 14.1. </del> <ins> 14.2. </ins> The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
described as legitimate.  Most of these functions can, however, be realized by other means.  For example, some DNS service providers offer customers the provision to "opt in" filtering services for <del> parental control and phishing protection.  Per-stream QoS can be </del> <ins> parental control and phishing protection.  Per-stream QoS could be </ins> provided by a combination of packet marking and end-to-end agreements.  As SNI encryption becomes common, we can expect more deployment of such "end-to-end" solutions.

Discussion:
Comments and discussion are found in issue . The proposed changes are minimal.
Once this is processed one way or another, I would like to publish a revised draft.
Thanks for clearly writing down attacks and requirements in this document. One small technical comment on this sentence: Sec 2.3: "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path. And two editorial comments: Sec 2.1: "The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information." "soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like: "The SNI was defined to facilitate management of servers, though other usages by middleboxes also take advantage of the information." or something similar... Also sec 2.1: "The SNI is probably also included in the general collection of metadata by pervasive surveillance actors." This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like: "The SNI could also be utilised by the general collection of metadata by pervasive surveillance actors."
Hi Christian, Please see below. From my point of view „some time after“ wouldn’t make it much better because I think the important part of the information of this sentence is that middleboxes use that information (for good or bad) and not who had the idea when. But again just a comment... Yes, removing end-to-end does help but it also sounds a bit as if that is a solution ready to use which I don’t think is the case. Maybe also say “could” instead “can” (to propose another minimal change)? Mirja >
Addressed in PR