jiebi/CodeConvo huggingface dataset:
Change:
Captive-Portal Identification in DHCP / RA <del> draft-ietf-capport-rfc7710bis-01 </del> <ins> draft-ietf-capport-rfc7710bis-02 </ins> Abstract

Discussion:
Earlier version of this document requested a parameter to be used for Link Relation purposes. This LinkRel use was removed as was the explicit parameter request, but the surround grammar was overlooked. Also: rev draft version to -02 and document month to February in anticipation of post a new version.
Change:
A signature algorithm <del> MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </del> <ins> MLS uses HPKE for public-key encryption I-D.irtf-cfrg-hpke.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol

Discussion:
HPKE is in the RFC Editor queue, so there shouldn't be any further changes.
MLS draft-12 still references draft-08 of HPKE, which is now on draft-12. We should update to the final version of HPKE before finalizing MLS.
Change:
be statically or dynamically configured.  Additionally the DetNet- aware forwarder does duplicate frame elimination based on the flow identification and the sequence number combination.  The packet <del> replication is also done within the DetNet-aware forwarder.  During elimination and the replication process the sequence number of the DetNet member flow MUST be preserved and copied to the egress DetNet member flow. </del> <ins> replication is also done within the DetNet-aware forwarder. 4.5.2. A DetNet Relay node operates in the DetNet forwarding sub-layer and service sub-layer.  For DetNet using MPLS forwarding related processing is performed on the F-Label.  This processing is done within an extended forwarder function.  Whether an ingress DetNet member flow receives DetNet specific processing depends on how the forwarding is programmed.  Some relay nodes may be DetNet service aware for certain DetNet services, while for other DetNet services these nodes may perform as unmodified LSRs that only understand how to switch MPLS-TE LSPs, i.e., as a transit nodes, see FAG.  Again, this is entirely up to how the forwarding has been programmed. During the elimination and replication process the sequence number of the ingress DetNet member flow MUST be preserved and copied to the corresponding egress DetNet member flow.  Specifically, a relay node sends the same sequence number in an outgoing packet of a DetNet member flow that is received in the corresponding incoming packet of a DetNet compound flow.  This is true whether or not PREOF is performed at the relay node. </ins> The internal design of a relay node is out of scope of this document. However the reader's attention is drawn to the need to make any PREOF state available to the packet processor(s) dealing with packets to which the PREOF functions must be applied, and to maintain that state <del> is such as way that it is available to the packet processor operation </del> <ins> is such away that it is available to the packet processor operation </ins> on the next packet in the DetNet flow (which may be a duplicate, a late packet, or the next packet in sequence. <del> 4.5.2. A DetNet Relay node operates in the DetNet forwarding sub-layer . For DetNet using MPLS this processing is performed on the F-Label. This processing is done within an extended forwarder function. Whether an ingress DetNet member flow receives DetNet specific processing depends on how the forwarding is programmed.  Some relay nodes may be DetNet service aware, while others may be unmodified LSRs that only understand how to switch MPLS-TE LSPs. It is also possible to treat the relay node as a transit node, see FAG.  Again, this is entirely up to how the forwarding has been programmed. </del> 4.6. 4.6.1.

Discussion:
Thanks for Don's fine tuning.
NAME cam you review and merge if you're good with the changes.
Change:
ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method should be used for matching the ECHClientHello to a known ECHConfig.  See optional-configs.  Unless <del> specified by the application using (D)TLS or externally configured on both sides, implementations MUST use the first method. </del> <ins> specified by the application using (D)TLS or externally configured, implementations MUST use the first method. </ins> The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension:

Discussion:
said to not use trial decryption unless "externally configured on both sides" but there's no way to know that, so I think the "on both sides" ought be deleted unless something else was intended.
Change:
are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- <del> D.shieh-rtcweb-ip-handling. </del> <ins> D.ietf-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

Discussion:
This is all strictly editorial and I think if either of you give it a quick scan, you can just merge it
LGTM - will merge
Change:
"Upgrade" (note that this requirement is case-insensitive as per HTTP). <del> the request SHALL include a single "Upgrade" header field with value "connect-udp". </del> <ins> the request SHALL include an "Upgrade" header field with value "connect-udp". </ins> For example, if the client is configured with URI Template "https://proxy.example.org/.well-known/masque/

Discussion:
"connect-udp". "Single" implies that this mechanism is incompatible with any other upgrade mechanisms. If that's actually the case, it might be good to state so explicitly, rather than rely on this single word.
Thanks for catching this oversight. Similar to , this was not the intent. Fixing via .
Change:
While protocols that use an explicit handshake to validate a Connection to a peer can be used for racing multiple establishment <del> attempts in parallel, "unconnected" protocols such as raw UDP do not </del> <ins> attempts in parallel, connectionless protocols such as raw UDP do not </ins> offer a way to validate the presence of a peer or the usability of a Connection without application feedback.  An implementation should consider such a protocol stack to be established as soon as the Transport Services system has selected a path on which to send data. However, if a peer is not reachable over the network using the <del> unconnected protocol, or data cannot be exchanged for any other </del> <ins> connectionless protocol, or data cannot be exchanged for any other </ins> reason, the application may want to attempt using another candidate Protocol Stack.  The implementation should maintain the list of other candidate Protocol Stacks that were eligible to use.

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
complete.  Otherwise, there are further steps, as described in the two following subsections. <del> Encryption below uses the AES-128-ECB cipher.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </del> <ins> Encryption below uses the AES-128-ECB cipher NIST-AES-ECB.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </ins> 4.3.1.

Discussion:
This needs a normative reference. There is likely a NIST SP with a number you can use somewhere.
Change:
For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation <del> procedures are defined in Section 4.3.7 of ECDSA and alternatively in </del> <ins> procedures are defined in Appendix D.1 of ECDP and alternatively in </ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct

Discussion:
FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.
Change:
to 1 the message is considered to be malformed and decompression fails as specified in item 3 of ver-req. <ins> The flag bits are registered in the OSCORE Octet registry specified in oscore-octet. </ins> The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0).

Discussion:
Solves issue (from review comments by NAME : URL) Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
<del> Requirements for Adaptive DNS Discovery draft-box-add-requirements-01 </del> <ins> Requirements for Discovering Designated Resolvers draft-box-add-requirements-02 </ins> Abstract Adaptive DNS Discovery is chartered to define mechanisms that allow clients to discover and select encrypted DNS resolvers.  This <del> document describes one common use case, that of discovering the encrypted DNS resolver that corresponds to the Do53 resolver offered by a network.  It lists requirements that any proposed discovery mechanisms should address. </del> <ins> document describes one common use case, namely that of clients that connect to a network but where they cannot securely authenticate the identity of that network.  In such cases the client would like to learn which encrypted DNS resolvers are designated by that network or by the Do53 resolver offered by that network.  It lists requirements that any proposed discovery mechanisms should seek to address. </ins> 1.

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
Clients MUST be prepared to do a cookie exchange with every handshake. <del> DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some reachability test; no such test is defined in this specification.  Even with such a test, an active on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </del> <ins> Some key properties required of the cookie for the cookie-exchange mechanism to be functional are described in Section 3.3 of RFC2522: the cookie MUST depend on the specific parties (i.e., 5-tuple) it MUST NOT be possible for anyone other than the issuing entity to generate cookies that are accepted as valid by that entity. This typically entails the use of a keyed MAC and secret key. cookie generation and verification are triggered by unauthenticated parties, and as such their resource consumption needs to be restrained in order to avoid having the cookie- exchange mechanism itself serve as a DoS vector. When cookies are generated using a keyed MAC (such as HMAC with a cryptographic hash function), it should be possible to rotate the associated secret key, so that temporary compromise of the key does not permanently compromise the integrity of the cookie-exchange mechanism.  Though this secret is not as high-value as, e.g., a session-ticket-encryption key, rotating the cookie-generation key on a similar timescale would ensure that the key-rotation functionality is exercised regularly and thus in working order. The cookie exchange provides address validation during the initial handshake.  DTLS with connection IDs allow for endpoint addresses to change during the association; any such updated addresses are not covered by the cookie exchange during the handshake.  DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some reachability test; no such test is defined in this specification. Even with such a test, an active on-path adversary can also black- hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS

Discussion:
Discuss the properties needed of cookies and some ancillary operational procedures, as well as mentioning that the DTLS record replay protection mechanism and 0-RTT replay protection mechanism play different roles and cannot substitute for each other.
Change:
3.3. Upon receipt, the Client handles the response and, if successful, <del> processes the body as follows: </del> <ins> deserializes the body values TokenResponse.evaluate_response and TokenResponse.evaluate_proof.  If deserialization of any value fails, the Client aborts the protocol.  Otherwise, when deserialization yields "evaluated_msg" and "proof", the Client processes the response as follows: </ins> If this succeeds, the Client then constructs a Token as follows:

Discussion:
draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME
Change:
the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke_decrypt_error".  Otherwise, it outputs the <del> resulting "input_share". </del> <ins> resulting "input_share".  The "OpenBase()" function is as specified in HPKE for the ciphersuite indicated by the HPKE configuration. </ins> 4.4.1.4.

Discussion:
I only tried searching for it, but all I found were places that it was used. This makes it difficult to determine which inputs are which. Which is the AAD, which is the plaintext, and which is the nonce? Please also describe the inputs in text. Note that at least one of the code blocks that use this is too wide at 76 characters.
SealBase() and SealOpen() refer to the "single-shot APIs" from URL I notice that we don't reference this explicitly. Would a reference suffice?
Change:
RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  In addition, several <del> KeyPurposeIds have been added RFC7299 under the IANA repository "SMI Security for PKIX Extended Key Purpose".  While usage of the </del> <ins> KeyPurposeIds have been added under the IANA repository "SMI Security for PKIX Extended Key Purpose" RFC7299.  While usage of the </ins> "anyExtendedKeyUsage" KeyPurposeId is bad practice for publicly trusted certificates, there is no public and general KeyPurposeId explicitly assigned for Document Signing.  The current practice is to

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."
Change:
NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits <del> set to '11' MUST revert to 5-tuple routing. </del> <ins> set to '11' MUST revert to 5-tuple routing.  These connection IDs may be of any length; however, see cid-entropy for limits on this length. </ins> 3.3.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
that Message are outstanding, there will be two Expired events delivered. <ins> The interface should allow the application to correlate which Send Action resulted in a particular Send Event.  The manner in which this correlation is indicated is implementation-specific. </ins> 7.3.1. The Sent Event occurs when a previous Send Action has completed,

Discussion:
Apple does this: URL URL it may be more convenient than what we currently have (or do we have it unspecified? My interpretation of our text would have been to use only one receive handler associated to the Connection). E.g., if an application expects 3 different types of messages to be received in sequence, it can hand over three different receive handlers in Apple's case, and that seems useful. Apple also has a "completion" handler per sent event, handed over as a parameter to "send". Is this necessary? Who needs 3 different "Sent" handlers for 3 different messages - shouldn't the "sent" handler rather be a singular per-Connection thing?
I think this gets into an implementation-specific area. If the language has an easy way to provide a unique completion/closure for a given invocation of Receive(), then I think it is preferable to do this to having a single function. If anything, it may be nice to make a not for Received() and Sent() that they should, if supported by the language, provide this kind of linking between calls and events.
I agree, and I assign this to Tommy since he offered (in an email) to write text. Thanks a lot!
Change:
Each MLS session uses a single ciphersuite that specifies the following primitives to be used in group key computations: <del> A hash function </del> <ins> HPKE parameters: A Key Encapsulation Mechanism (KEM) </ins> <del> A key encapsulation mechanism (KEM) </del> <ins> A Key Derivation Fucntion (KDF) </ins> <del> An AEAD encryption algorithm </del> <ins> An AEAD encryption algorithm </ins> A signature algorithm <del> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </del> <ins> The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke for the purpose of public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
<del> An HTTPS-based Transport for Configured Subscriptions </del> <ins> An HTTPS-based Transport for YANG Notifications </ins> draft-ietf-netconf-https-notif-latest Abstract

Discussion:
Updates based on reviewing comments from Martin and Jan.
I was expecting more changes. What about the Title?
good enough but, FYI, there's no need to set the "abbrev" attribute if it's the same value as the title...
Looks like the "abbrev" text is too long. How about "HTTPS YANG Notifications"?
Or maybe "HTTPS Notif Transport" ??? Either way is fine by me.