jiebi/CodeConvo huggingface dataset:
Change:
issue other signed objects as long as the certificate contains the digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that <del> are needed for this application. </del> <ins> are needed for this application.  The credential has the following structure: </ins> <del> Relative time in seconds from the beginning of the certificate's notBefore value after which the delegated credential is no longer valid. </del> <ins> Relative time in seconds from the beginning of the delegation certificate's notBefore value after which the delegated credential is no longer valid. The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in the TLS 1.3 standard. The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in TLS 1.3. </ins> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. <ins> The delegated credential has the following structure: </ins> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard.

Discussion:
Based on There is currently no binding of the credential to the signature scheme used to sign the handshake. The field of the encodes the DC public key type; but there's not a one-to-one correspondence between X.509's and TLS . Hence, the TLS terminator could use a signature scheme to sign the handshake other than the scheme intended by the delegator. To prevent this, this PR adds the SignatureScheme that the TLS terminator selects in the "signature_algorithms" extension to scope of the delegation signature. In addition, it makes this and the protocol version explicit parameters of the Credential structure. This is intended to make debugging easier.
Change:
Abstract <del> QUIC connection IDs allow continuation of connections across address/ port 4-tuple changes, and can store routing information for stateless or low-state load balancers.  They also can prevent linkability of connections across deliberate address migration through the use of protected communications between client and server.  This creates issues for load-balancing intermediaries.  This specification standardizes methods for encoding routing information given a small set of configuration parameters.  This framework also enables offload of other QUIC functions to trusted intermediaries, given the explicit cooperation of the QUIC server. </del> <ins> The QUIC protocol design is resistant to transparent packet inspection, injection, and modification by intermediaries.  However, the server can explicitly cooperate with network services by agreeing to certain conventions and/or sharing state with those services. This specification provides a standardized means of solving three problems: (1) maintaining routability to servers via a low-state load balancer even when the connection IDs in use change; (2) explicit encoding of the connection ID length in all packets to assist hardware accelerators; and (3) injection of QUIC Retry packets by an anti-Denial-of-Service agent on behalf of the server. </ins> 1.

Discussion:
Less emphasis on load balancers, more on the other stuff. More text on the use cases and less on "how".
Change:
This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" <del> extension has been assigned a code point of TBD.  The IANA registry </del> <ins> extension has been assigned a code point of 34.  The IANA registry </ins> lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.

Discussion:
Currently the codepoint is TBD
NAME does one know what we need to get a code point.
NAME if we want one early, we can kick that process off. If not we wait for it to be assigned later in the process.
I think we need an early one. It's not possible yet to implement this to evaluate in various scenarios. We plan to use delegated credentials in our internal infrastructure and then probably would push the implementation back to open source projects like OpenSSL.
i think a resolution to URL is the only thing that is probably holding back the code point.
NAME can you please start the code point allocation process now that is resolved?
Change:
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message.  The client will also send a ClientHello when the server has responded to its ClientHello with <del> a HelloRetryRequest that selects cryptographic parameters that don't match the client's "key_share" extension.  In that case, the client MUST send the same ClientHello (without modification) except: </del> <ins> a HelloRetryRequest.  In that case, the client MUST send the same ClientHello (without modification) except: </ins> Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).

Discussion:
In the first paragraph, remove "that selects cryptographic parameters that don’t match the client’s 'keyshare' extension". Reason: According to section 4.2.5, HelloRetryRequest might not include the “keyshare” extension. Also there is a whole section for Hello Retry Request. So I don't think we need to explain what a HelloRetryRequest is here.
Change:
<del> (a) An adjective to describe a name server whose name is either </del> <ins> An adjective to describe a name server whose name is either </ins> subordinate to or (rarely) the same as the zone origin.  In- <del> bailiwick name servers require glue records in their parent zone </del> <ins> bailiwick name servers may have glue records in their parent zone </ins> (using the first of the definitions of "glue records" in the <del> definition above). (b) Data for which the server is either authoritative, or else authoritative for an ancestor of the owner name.  This sense of the term normally is used when discussing the relevancy of glue records in a response.  For example, the server for the parent zone "example.com" might reply with glue records for "ns.child.example.com".  Because the "child.example.com" zone is a descendant of the "example.com" zone, the glue records are in- bailiwick. The antonym of in-bailiwick. </del> <ins> definition above).  'In-bailiwick' names are divided into two type of name server names: 'in-domain' names and 'Sibling domain' names. An adjective to describe a name server whose name is either subordinate to or (rarely) the same as the ownwer name of the NS resource records.  In-domain name server name MUST have glue records or name resolution fails.  For example, a delegation for "child.example.com" may have "in-domain" name server name "ns.child.example.com". A name server's name that is either subordinate to or (rarely) the same as the zone origin and not subordinate to or the same as the owner name of the NS resource records.  Glue records for sibling domains are allowed, but not necessary.  For example, a delegation for "child.example.com" in "example.com" zone may have "Sibling" name server name "ns.another.example.com". The antonym of in-bailiwick.  An adjective to describe a name server whose name is not subordinate to or the same as the zone origin.  Glue records for out-of-bailiwick name servers are useless. </ins> "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom

Discussion:
Two definitions of In-bailiwick are unclear and seems the same. In-bailiwick name server names have two meanings. One is narrow and requires glue records. The other is wide and may have glue records. There are needs to distinguish two types of in-bailiwick name server names. Ondrej Sury used NS Types as in OARC 26. URL Peter Koch proposed "in domain", "sibing domain", and "unrelated". "unrelated" is out-of-bailiwick. URL I propose to add "in domain" and "sibling domain", update "in-bailiwick" and add a description for "out-of-bailiwick". If this proposal is reasonable, please improve the text and merge.
lgtm (apart from the typo)
I like the idea but still, this is sufficiently muddy area to warrant short example for each type. It will be great with examples and I will definitely support the new wording over the old one.
Change:
unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. <del> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the client provides the server with an invalid or unsupported contact URL, then the server MUST return an error of type "invalidContact", with a description describing the error and what types of contact URL the server considers acceptable. </del> <ins> The server SHOULD validate that the contact URIs in the "contact" field are valid and supported by the server.  If the server validates contact URIs it MUST support the "mailto" scheme.  If the server rejects a contact URI for using an unsupported scheme it MUST return an error of type "unsupportedContact", with a description describing the error and what types of contact URIs the server considers acceptable.  If the server rejects a contact URI for using a supported scheme but an invalid value then the server MUST return an error of type "invalidContact". </ins> The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to

Discussion:
Firstly, this PR updates the table of errors in Section 6.6 "Errors" to add an "unsupportedContact" error type in addition to "invalidContact". The former is returned when the contact URI protocol is unsupported and the latter when the protocol is supported but the provided contact is invalid. Secondly, this PR updates Section 7.3 "Account Creation" to both mention the new "unsupportedContact" error type and to make support of the "mailto:" protocol a MUST.
Thanks for the feedback NAME - updated.
Should the "unsupportedContact" error include a separate machine-readable field with the types of contacts acceptable?
NAME Let's discuss that in a follow-on issue / PR.
Change:
value smaller than the "min_ack_delay" advertised by this endpoint is invalid. <del> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated </del> <ins> Receipt of invalid values in an ACK_FREQUENCY frame MUST be treated </ins> as a connection error of type FRAME_ENCODING_ERROR. <del> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not </del> <ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not </ins> require retransmission. <del> An endpoint MAY send ACK-FREQUENCY frames multiple times during a </del> <ins> An endpoint MAY send ACK_FREQUENCY frames multiple times during a </ins> connection and with different values. An endpoint will have committed a "max_ack_delay" value to the peer, which specifies the maximum amount of time by which the endpoint will <del> delay sending acknowledgments.  When the endpoint receives an ACK- FREQUENCY frame, it MUST update this maximum time to the value </del> <ins> delay sending acknowledgments.  When the endpoint receives an ACK_FREQUENCY frame, it MUST update this maximum time to the value </ins> proposed by the peer in the Update Max Ack Delay field. 5. <del> An endpoint can send multiple ACK-FREQUENCY frames, and each one of </del> <ins> An endpoint can send multiple ACK_FREQUENCY frames, and each one of </ins> them can have different values.  An endpoint MUST use a sequence <del> number of 0 for the first ACK-FREQUENCY frame it constructs and </del> <ins> number of 0 for the first ACK_FREQUENCY frame it constructs and </ins> sends, and a strictly increasing value thereafter. <del> An endpoint MUST allow reordered ACK-FREQUENCY frames to be received </del> <ins> An endpoint MUST allow reordered ACK_FREQUENCY frames to be received </ins> and processed, see Section 13.3 of QUIC-TRANSPORT. <del> On the first received ACK-FREQUENCY frame in a connection, an </del> <ins> On the first received ACK_FREQUENCY frame in a connection, an </ins> endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence number.  The new Packet Tolerance and Update Max Ack Delay values MUST be immediately used for delaying acknowledgements; see sending. <del> On a subsequently received ACK-FREQUENCY frame, the endpoint MUST </del> <ins> On a subsequently received ACK_FREQUENCY frame, the endpoint MUST </ins> check if this frame is more recent than any previous ones, as follows:

Discussion:
Also rename ACK-FREQUENCY to ACK_FREQUENCY to
Use instead of following naming convention in the transport draft.
Change:
from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. <del> The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. </del> <ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal connection close; see Section 6.1 of TLS13.  As QUIC provides alternative mechanisms for connection termination and the TLS connection is only closed if an error is encountered, a QUIC endpoint MUST treat any alert from TLS as if it were at the "fatal" level. </ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this

Discussion:
This changes the shape of the requirement from one that proscribes the behaviour of a TLS stack to the reaction of QUIC to a warning level alert. This recommends treating them as fatal as QUIC never deliberately closes TLS. This is a normative change that should have no practical effect on implementations.
NAME said:
I'm going to request that we flag this one "design". I think that we want to say: the TLS connection is never closed using TLS mechanisms QUIC can treat any TLS alert as fatal PR created and email in the pipe.
Marking this as design as requested.
Returning to an open state as the chairs directed in their plan.
Closing this now that the IESG have approved the document(s).
I agree that this is a good improvement, especially for folks who can't modify their TLS stack.
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 <del> This document defines both a protocol for sending notifications over HTTPS as well as extensions to the data model for configured subscriptions defined in RFC 8639.  It also presents an example module for configuration without using the data model defined in RFC 8639. </del> <ins> This document defines a protocol for sending notifications over HTTPS.  YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. </ins> This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is

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:
This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, <del> new link attributes useful in conjunction with a Resource Directory </del> <ins> new target attributes useful in conjunction with a Resource Directory </ins> are defined.  Although the examples in this document show the use of these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230.

Discussion:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.
Change:
undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections. <del> Both are intended for use by HTTP extensions, not applications. </del> <ins> HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. </ins> 1.

Discussion:
In Abstract: "Both are intended for use by HTTP extensions, not applications." I think instead of using Both which is unclear, rather say HTTP Datagram and Capsule Protocol. That is at least what I interpret it to be in reference to.
Agree, we should just write this out explicitly.
SGTM
Change:
implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation <del> described below; all dimensions assume square pixels. </del> <ins> described below; all dimensions are measured in pixels, whether square or not. </ins> 3.6.1.

Discussion:
LGTM
LGTM
The text says "all dimensions assume square pixels". Given the affordance for non-square pixels elsewhere, I think this should say "all dimensions are measured in pixels, whether square or not".
Agreed.
Change:
the "path" field at its discretion. If populating the "path" field: Create a UpdatePath using the new <del> tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. </del> <ins> tree.  Any new member (from an add proposal) MUST be exluded from the resolution during the computation of the UpdatePath.  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. </ins> Assign this UpdatePath to the "path" field in the Commit.

Discussion:
As briefly explained in the mailing list, commit messages currently contain encryptions for newly added group members that never even receive this commit message. This PR explicitely exlcudes them during the preparation of the UpdatePath.
I think this is a good point that wasn't really specified so far. The wording sounds a bit convoluted, maybe there is an easier way to describe it, like saying that the final resolution list should be filtered and all new leaf nodes should be removed from it.
Change:
During the handshake, endpoints will exchange Version Information, which is a blob of data that is defined below.  In QUIC version 1, the Version Information is transmitted using a new transport <del> parameter, "version_information".  The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> parameter, version_information.  The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of QUIC): </ins> The content of each field is described below:

Discussion:
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
Change:
different requirements for determining whether to accept or reject early data. <del> 4.9. </del> <ins> 4.7. </ins> In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of TLS13) can be used to correct a client's incorrect KeyShare extension

Discussion:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.
Change:
8.12. <del> IANA has added the media type "application/edhoc" to the CoAP Content-Formats registry. </del> <ins> IANA has added the media type "application/edhoc" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </ins> Media Type: application/edhoc

Discussion:
A new Resource Type (rt=) Link Target attribute like "URL" may be registered in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
That seems like a good idea.
Marco, do you want to provide a PR? Then we could merge that for -11
Done, see URL Note that the first commit is just about removing trailing whitespace to avoid compiling errors. The content you need is in the commit URL
Looks good. I tried to align the whole IANA section with RFC 8126. Then I merged.