jiebi/CodeConvo huggingface dataset:
Change:
The encrypted SNI is carried in an "encrypted_server_name" extension, which contains an EncryptedSNI structure: <ins> The cipher suite used to encrypt the SNI. The KeyShareEntry carrying the client's public ephemeral key shared used to derive the ESNI key. </ins> A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure.  This hash is computed using the hash function associated with "suite". <del> The cipher suite used to encrypt the SNI. </del> The original ServerNameList from the "server_name" extension, padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below.

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is <del> provided, it is zero-length. </del> <ins> provided, the certificate_request_context can be chosen arbitrarily. </ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version

Discussion:
Make it possible to choose a non-empty certificaterequestcontext when there is no authenticator request. This change introduces the flexibility needed to achieve compound authentication between certificates using a technique called CRC Smuggling, described by Jonathan Hoyland.
Change:
Once the ICE/DTLS session is set up, the media will flow unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (Media Server).  In order to reduce <del> complexity, no SDP renegotiation is supported, so no tracks or streams can be added or removed once the initial SDP offer/answer over HTTP is completed. </del> <ins> complexity, no SDP renegotiation is supported, so no "m=" sections can be added once the initial SDP offer/answer over HTTP is completed. </ins> 4.

Discussion:
Looks good.
thank you Bernard!
from NAME Section 2 I do not see a definition of “track”. I think this is important to clarify. Section 4.2 “ While this version of the specification only supports a single audio and video track, in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response.”
updated the PR to add MediaStream/MediaStreamTrack references
Change:
Section 5.1. An implementation MUST support the provisioning for handling any <del> received DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. </del> <ins> packet flows received via DetNet MPLS data plane as DetNet IP flows via configuration.  Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. </ins> Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate

Discussion:
Changes: 1, Section “5. IP over DetNet MPLS Procedures” Add new text before section 5.1. 2, Fix a nit in penultimate paragraph of “5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures”
Change:
Expand, and instantiated with the EDHOC AEAD algorithm in the selected cipher suite. <del> where info is the CBOR encoding of </del> <ins> where info is encoded as the CBOR sequence </ins> where

Discussion:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to
Change:
Note that the same bytes of the ServerHello.random are used to implement downgrade protection for TLS 1.3 (see RFC8446, <del> Section 4.1.3).  The backend server's signal of acceptance does not interfere with this mechanism because ECH is only supported in TLS 1.3 or higher. </del> <ins> Section 4.1.3).  These mechanisms do not interfere because the backend server only signals ECH acceptance in TLS 1.3 or higher. </ins> 10.8.

Discussion:
As written, the backend server performs this URL modification unconditionally when it sees an empty ECH extension. Although the client is required to only offer TLS 1.3, the backend server doesn't check this. However, as noted elsewhere in the document, these same 8 bytes are used for the TLS 1.3 downgrade protection mechanism. That mechanism only works if the server never produces a TLS 1.2 ServerKeyExchange signature without the signal, so it's important that the server not signal ECH acceptance. Write this down.
Oops. Good catch!Yup, this is a good idea.
Change:
a number of protocol elements that it needs to manage, including nonces, references, keys, access tokens, and other elements.  During the interaction process, the client instance usually hands control of <del> the user experience over to another component, beit the system </del> <ins> the user experience over to another component, be it the system </ins> browser, another application, or some action the resource owner is instructed to take on another device.  In order for the client instance to make its continuation call, it will need to recall all of

Discussion:
type, - beit -> be it,
To edit notification comments on pull requests, go to your .
"beit" isn't a word, it should be "be it".
As I was reading through the latest version of the draft, I spotted a typo within section 2.1.1. It should says accesstoken object, not acccess_token object.
Change:
the client has advertised or a Push ID which has already been promised as a connection error of type HTTP_MALFORMED_FRAME. <del> If a PUSH_PROMISE frame is received on either control stream, the recipient MUST respond with a connection error (errors) of type </del> <ins> If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error (errors) of type </ins> HTTP_WRONG_STREAM. <ins> A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the receipt of a PUSH_PROMISE frame as a connection error of type HTTP_UNEXPECTED_FRAME. </ins> See server-push for a description of the overall server push mechanism.

Discussion:
This pr changes the server's error on receipt of a PUSHPROMISE frame. While the current draft implicitly suggests push promises can only be sent by the server, it doesn't explicitly disallow clients from sending PUSHPROMISE frames. This pr explicitly disallows clients from sending PUSHPROMISE frames and requires the server to treat each receipt of a PUSHPROMISE frame as a connection error of type HTTPUNEXPECTEDFRAME.
Change:
unless it is responding to errors it detects before removing encapsulation of the request; see errors. <ins> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities. </ins> 5.1. This encapsulation does not permit progressive processing of

Discussion:
So add some forward references.
Sections 6.1, 6.2 and 6.3 detail normative requirements that seem to apply to the actors duties outlined in section 5. Consider forward references to each respective section to aid implementers in discovery applicable considerations.
Change:
TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. <ins> IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </ins> 16. Specification Required RFC5226 registry requests are registered after

Discussion:
This text is taken from TLS1.3. The point is to reserve the remaining values as a really big hint to "not look here, go look over there".
Change:
UEFI event logs. 'ima': Indicates that the device supports the retrieval of event <del> logs from the Linux Integrity Measurement Architecture (IMA ima- log).  Also see ima. </del> <ins> logs from the Linux Integrity Measurement Architecture (IMA, see ima). </ins> 'netequip_boot': Indicates that the device supports the retrieval of netequip boot event logs.  See ima and netequip-boot-log.

Discussion:
NAME I did what I could in the time remaining. Please check and I think there are only two comments left unaddressed.
Change:
SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 <del> and layer-1 encapsulations.  PEP could host coding techniques and thus support the use-cases that have been discussed in this document. </del> <ins> and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus support use-cases that have been discussed in this document. </ins> Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a <del> SATCOM link.  However, there is a research issue in the recurrent trade-off in SATCOM systems: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? </del> <ins> SATCOM link.  This leads to research question on the interaction between coding schemes and TCP congestion controls. </ins> 4.2. <ins> The recurrent trade-off in SATCOM systems remains: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? 4.3. </ins> Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This

Discussion:
This section deserves a small introduction where you explain that you discuss a few topics, without trying to be exhaustive. Section 5.1 Are PEP part of "Network Functions"? What's their position in the architecture of Fig. 1?I don't understand why the question on code rate to use is in a challenge called "increased deployability". I'd rather put it in a challenge on dynamic adaptation (which is not identified).
Corrected and answered in PR
Change:
indicates that the Finished value is to be truncated to the given length.  When the transcript is reconstructed, the remainder of <del> the Finished value is filled in by the receiving side.  [[OPEN ISSUE: How short should we allow this to be?  TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes.  More analysis is needed to know the minimum safe Finished size.  See RFC8446; Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA.]] </del> <ins> the Finished value is filled in by the receiving side. </ins> <del> 5.1.1. </del> <ins> [[OPEN ISSUE: How short should we allow this to be?  TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes.  More analysis is needed to know the minimum safe Finished size.  See RFC8446; Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA.]] 3.2.1. </ins> To be compatible with the specializations described in this section, <del> a TLS stack needs to provide two key features: </del> <ins> a TLS stack needs to provide the following features: </ins> <del> If specialization of extensions is to be used, then the TLS stack MUST order each vector of Extension values in ascending order according to the ExtensionType.  This allows for a deterministic reconstruction of the extension list. </del> <ins> If specialization of extensions is to be used, then the TLS stack MUST order each vector of Extension values in ascending order according to the ExtensionType.  This allows for a deterministic reconstruction of the extension list. </ins> <del> If truncated Random values are to be used, then the TLS stack MUST be configurable to set the remaining bytes of the random values to zero. This ensures that the reconstructed, padded random value matches the original. </del> <ins> If truncated Random values are to be used, then the TLS stack MUST be configurable to set the remaining bytes of the random values to zero.  This ensures that the reconstructed, padded random value matches the original. </ins> <del> If truncated Finished values are to be used, then the TLS stack MUST be configurable so that only the provided bytes of the Finished are verified, or so that the expected remaining values can be computed. </del> <ins> If truncated Finished values are to be used, then the TLS stack MUST be configurable so that only the provided bytes of the Finished are verified, or so that the expected remaining values can be computed. </ins> <del> 5.1.2. </del> <ins> 3.2.2. </ins> Extensions used in the ClientHello, ServerHello, EncryptedExtensions, and CertificateRequest messages can be "predefined" in a compression

Discussion:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.
Change:
Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets. <ins> The "Spec" column in frame-types summarizes any special rules governing the processing or generation of the frame type, as indicated by the following characters: Packets containing only frames with this marking are not ack- eliciting; see generating-acks. Packets containing only frames with this marking do not count toward bytes in flight for congestion control purposes; see QUIC- RECOVERY. Packets containing only frames with this marking can be used to probe new network paths during connection migration; see probing. The content of frames with this marking are flow controlled; see flow-control. The "Pkts" and "Spec" columns in frame-types do not form part of the IANA registry; see iana-frames. </ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR.

Discussion:
After considering this a little more it seems helpful to bring some of the special handling rules up into the summary. We don't really give up-front treatment of ack-eliciting, probing, and other important distinctions, so an extra column seemed useful. A table of this size just fits in the text format.
I had almost exactly those changes in a previous version. It was a near thing.
That is super helpful, and is the direction I was hoping for!
In Section Frame Types and Formats, there is a very useful summary of frame types by packet type. As a person with a CC and transport protocol interest, it would be really nice to have had a summary table of key properties that included whether each frame type is ack-eliciting; whether transmission is controlled by flow-control; and whether transmission is controlled by congestion-control. Is there any chance we can add an extra column say to this table?
The problem with the table is that it is already essentially the full width available to us. That makes the addition of more information quite difficult. The rules for most of these are simple enough that I'm not sure that the table is the best way to present it. That is: ack-eliciting: all except ACK, PADDING congestion-controlled: all except ACK flow controlled: only STREAM
I wouldn't want to mess-up the table format to include the info. However, it would be really nice to have the info in a compact way close to the table somehow so that readers quickly confirm this. Would a note below the table possibly work, saying just this?
Change:
Relies upon application-specific classification. Groups a set of parameters that are used when CsC is enabled such <del> the use of BGP for signalling purposes RFC8277. </del> <ins> the use of BGP for signaling purposes RFC8277. </ins> Time synchronization may be needed in some VPNs such as infrastructure and management VPNs.  This container is used to

Discussion:
The term was used with signalling and signaling. I modified it to signaling, so it is aligned with L2NM as well
Change:
The HEADERS frame (type=0x1) is used to carry a header block, compressed using QPACK.  See QPACK for more details. <del> HEADERS frames can only be sent on request / push streams. </del> <ins> HEADERS frames can only be sent on request / push streams.  If a HEADERS frame is received on a control stream, the recipient MUST respond with a connection error (errors) of type HTTP_WRONG_STREAM. </ins> 7.2.3.

Discussion:
Receiving a HEADERS frame on a control stream should result in a connection error of type HTTPWRONGSTREAM. The correct error is documented for all other frame types except for HEADERS. This pr specifies the error for HEADERS frames as well.
This inconsistency was bugging me the other day. So thanks for beating me to fixing it :) NAME iff gets traction, we'd need a sweep of all these If a HEADERS frame is received on either control stream phrases to cover all streams (exclusively or inclusively).
NAME was closed. Is there anything else that's blocking this pr from being merged?
NAME I added NAME so he can review and merge this.
Change:
RFC8639, the notification method defined in this document MAY be used outside of RFC8639 by using some of the definitions from this module along with the grouping defined in I-D.ietf-netconf-http-client- <del> server.  For an example on how that can be done, see Section 8.2. </del> <ins> server.  For an example on how that can be done, see Section A.2. </ins> 1.2.

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
should be deployed to ensure the privacy of clients and the security of all participating entities. <ins> The privacypass working group is working on HTTP-Authentication as an instantiation of a redemption protocol and ISSUANCE as an instantiation of the issuance protocol. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL
Change:
regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables <del> that enable executing on constructs such as "p{IsCoptic}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into codepoint-range matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </del> <ins> that enable executing constructs such as "p{Nd}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into character-class matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </ins> 7.

Discussion:
I think it is better to support script names than block names for and . Unicode block names are not supported by regexp implementations an interoperable way. Block names as specified in URL allow ASCII alpha-numerics, hyphens and spec. Unicode says these names are supposed to be matched using URL (which says to ignore case, whitespace, underscore, hyphens, and any initial prefix string "is"). But implementations don't do this and compare names using a wide variety of different rules (as partially described by "Unicode blocks" section of https://www.regular-URL). Usage of block names can easily be replaced by ranges. Furthermore, block names are not covered by the Unicode stability policy. Scripts names don't have such a wide range of characters (there are also 4-char short script names) and scripts are generally preferable to blocks for regexps as explained here: URL Script is in the minimal list of properties that Unicode requires but block is not URL
Thank you! Very useful input. We are having an interim meeting (per web conference) of the JSONPath WG at this very moment; I'll look at this later today.
I just looked again at XSD and see that sadly it doesn't support scripts in . Every major regex implementation that I am aware of that does Unicode and does support scripts (Go, PCRE, Java, C#, Ruby). So if XSD compatibility is crucial (not sure why it would be at this point), my suggestion would be just to get rid of blocks. One could argue that supporting only the general category in is consistent with not supporting character set intersection/difference: once you have multiple things (e.g. script and category), you really need to be able to have intersections/differences of them.
Change:
its control over a domain name by proving that it can provision resources on an HTTP server that responds for that domain name.  The ACME server challenges the client to provision a file with a specific <del> string as its contents. </del> <ins> JWS as its contents. </ins> As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
The following parameters are defined: <del> The "w" parameter specifies a time window.  Its syntax is a "time- window" defined in time-window. </del> <ins> The REQUIRED "w" parameter specifies a time window.  Its syntax is a "time-window" defined in time-window. </ins> Other parameters are allowed and can be regarded as comments.  They ought to be registered within the "Hypertext Transfer Protocol (HTTP)

Discussion:
Clarifies that Without w a quota-policy is meaningless, so it's just a clarification.
Oops, this should have been explicit since day 1! Good catch!