jiebi/CodeConvo huggingface dataset:
Change:
Notes: <del> "OptionalNodeOrValue" is an abstraction of a "comparable" (which may appear on either side of a comparison or as a function </del> <ins> "OptionalNodeOrValueType" is an abstraction of a "comparable" (which may appear on either side of a comparison or as a function </ins> argument). <del> "OptionalNode" is an abstraction of a Singular Path. </del> <ins> "OptionalNodeType" is an abstraction of a Singular Path. </ins> <del> "Value" is an abstraction of a primitive value. </del> <ins> "ValueType" is an abstraction of a primitive value. </ins> <del> "Boolean" is an abstraction of a primitive value that is either "true" or "false". </del> <ins> "BooleanType" is an abstraction of a primitive value that is either "true" or "false". </ins> <del> "OptionalValue" is an abstraction of a primitive value that may alternatively be absent ("Nothing"). </del> <ins> "OptionalValueType" is an abstraction of a primitive value that may alternatively be absent ("Nothing"). </ins> <del> "OptionalNodes" is an abstraction of a "filter-path" (which </del> <ins> "OptionalNodesType" is an abstraction of a "filter-path" (which </ins> appears in a test expression or as a function argument). The abstract instances above can be obtained from the concrete

Discussion:
This is literally just a renaming of the names in the Type column of Table 13. I also noticed that the description doesn't account for non-nodelist inputs. I'll open another issue for that.
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
Thanks!
Change:
Resource lookup results in links that are semantically equivalent to the links submitted to the RD if they were accessed on the endpoint itself.  The links and link parameters returned are equal to the <del> submitted ones except for anchor, which gets resolved according to the endpoint's context.  That allows the client to interpret the response as links without any further knowledge of what the RD does. The Resource Directory MAY replace the contexts with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for CoAP endpoints. </del> <ins> submitted ones except for anchor, which was resolved by the server against the endpoint's context. Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) context URI of the registration as the anchor.  Links whose anchor was submitted as an absolute URI are returned as they were registered.  The hrefs of links can always be served as they were submitted; the server MAY return relative references in absolute form in to resource lookups, but that results in needlessly verbose responses. That allows the client to interpret the response as links without any further knowledge of what the RD does.  The Resource Directory MAY replace the contexts with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for CoAP endpoints. </ins> Endpoint and group lookups result in links to the selected registration resource and group resources.  Endpoint registration

Discussion:
The first commit tries to get across the difference between the relative references in the serialization and the URIs in the model more clearly. The second commit adds paragraphs to the descriptions of various operations about how and by whom URIs are resolved in those steps.
Change:
Consumers MUST use "type" as primary identifiers for the problem type; the "title" string is advisory and included only for consumers <del> who are not aware of the semantics of the "type" value. </del> <ins> who are not aware of the semantics of the "type" value.  An initial set of "type"s and corresponding "title"s is defined in sec-response- code-types. </ins> The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information.

Discussion:
Note that this PR sits on top of
CoAP Response Codes are an optional feature and should be discussed in a separate section. Rationale for the feature The CoAP response-code is already carried by the CoAP header, so it doesn't make sense adding it to the PD payload that goes from Server to Client. It does however make sense for a Client that is about to ingest the received PD into a log pipeline to "enrich" it with ancillary Information from the underlying CoAP transaction. In this context, response-code is probably the most basic attribute that one wants to carry over as it is also commonly used as a high-level partition key for log visualisation.
addressed by
We should provide a default set of ready-to-use PD types associated with the existing CoAP status codes, intended for carrying (and enriching) the associated status code semantics. The (rough) plan is to define an “about:coap” namespace with one PD type for each registered . An application could use such PDs without the need to register anything. Just pick the "right" type and populate the relevant fields, job done. As a nice side-effect, this would allow exercising the registration procedure, including the definition of the PD type's registry structure and providing a first set of registrations.
Change:
the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT. <del> 2.6. </del> <ins> 2.7. </ins> The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet

Discussion:
also to address issue
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Change:
content.  response describes the process for constructing and processing an Encapsulated Response. <del> The Nenc and Nk parameters corresponding to the HpkeKdfId can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes; Nk refers to the size of the AEAD key for the HPKE ciphersuite, in bits. </del> <ins> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The Encapsulated Response nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.1.

Discussion:
In Section 4, there are two statements for Encapsulated Request and Encapsulate Response respectively These are the only places that is used. The HPKE spec doesn't use the term either. Doing some digging, it seemed like an older draft defined this term (and others); see URL But it seems like you moved away from that and this is a hangover
So this isn't ideal. It is also wrong. It would be HpkeKemId in the first instance and HpkeAeadId in the second. The second also refers to Nenc without using it. The second also neglected to mention Nn, which was in the algorithm. What a mess. I've cleaned it up, but would appreciate someone double-checking my work.
This addresses the issue I created, thanks. I can't vouch for the correctness of the crypto pieces though
Change:
4.2.8. <del> perMsgChecksumRecv </del> <ins> FullChecksumRecv </ins> Preference

Discussion:
Why is the name not rather something like perMsgChecksumFullSend?
Happy with a change if making this more consistent.
There are some related changes in
NAME : Did the merged PR 839 happen to address this? - If not please make a PR.
NAME PR 839 updated the name, but still found it confusing so made a PR.
See review.
I do not mind what the name is called as long as it is clear. I think the proposal looks good.
Change:
This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. <del> The interfaces between these protocols and transports are described in transport-interface; the interfaces between these protocols and applications are described in application-interface. </del> <ins> These protocols are grouped based on where in the protocol stack they are implemented, which influences which parts of a packet they protect: Generic application payload, application payload for specific application-layer protocols, both application payload and transport headers, or entire IP packets. Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination with other protocols.  One major reason for this is that channel security protocols often consist of two components: A handshake protocol, which is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys. A record protocol, which is used to encrypt traffic using keys and parameters provided by the handshake protocol. For some protocols, such as tcpcrypt, these two components are tightly integrated.  In contrast, for IPsec, these components are implemented in separate protocols: AH and ESP are record protocols, which can use keys supplied by the handshake protocol IKEv2, by other handshake protocols, or by manual configuration.  Moreover, some protocols can be used in different ways: While the base TLS protocol as defined in RFC8446 has an integrated handshake and record protocol, TLS or DTLS can also be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake protocol can be used with a separate record layer, as in QUIC. </ins> 3.1.

Discussion:
This PR mainly changes the beginning of Section 3, Transport Security Protocol Descriptions. It substitutes the sentence on how the document is structured (which I moved to the Introduction) with a brief discussion on the classification we use in Section 3. This includes an explanation of the difference between handshake and record protocols as suggested by Ekr. Furthermore, this PR references DTLS-SRTP, renames "QUIC + TLS" to "IETF QUIC", and mentions that OpenVPN can use TLS as a handshake protocol.
Thank you!
Change:
implment also the DetNet service layer functions.  An S-Label is also used to identify a DetNet flow at DetNet service layer. <ins> [Note to the editors this section is not needed.  This is internal to the node.  With pseudowires we needed global identifier for the control plane to identfy the PW to the node, and we used platform label space to ensure the PW was identiable when it was received. I think this can be deleted - SB] </ins> A DetNet Edge and Relay node internal construct that uniquely identifies a DetNet flow within a node and never appear on-wire. It may be used to select proper forwarding and/or DetNet specific

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the <del> operator as a "delegated credential". </del> <ins> operator as a "delegated credential" or "DC". </ins> 1.1.

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
The definition for each media type is in the following subsections. <del> 8.2.1. </del> <ins> 8.3.1. </ins> application

Discussion:
While we're here, I'd like to recommend we align the name of this well-known value to align with the request/response names. In particular, what do folks think about "/well-known/private-token-issuer-directory"?
you're probably missing a registration for your well-known in the IANA considerations, the registry is URL
Change:
all Connections are defined in the subsections below. Note that many protocol properties have a corresponding selection <del> property, which prefers protocols providing a specific transport feature that controlled by that protocol property.  [EDITOR'S NOTE: todo: add these cross-references up to selection-props] </del> <ins> property, which prefers protocols providing a supporting transport feature. </ins> 11.1.1.

Discussion:
This also addresses two inline [EDITOR's NOTE] items. One was about the per-message override capacity profile being inconsistent with the other one; this was solved by removing details, such that the other one defines the possible choices. Another was about selection vs. connection properties, with broken text. There was no need to add the references as the editor's note says, I thought.
this LGTM, thanks!
Change:
The guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In this case, the user's web server is intended to speak for one or more domains, and the process of certificate <del> issuance is intended to verify that this server actually speaks for the domain(s). </del> <ins> issuance is intended to verify that this web server actually speaks for the domain(s). </ins> DV certificate validation commonly checks claims about properties related to control of a domain name - properties that can be observed

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator.  These <del> messages do not include any TLS framing and are not encrypted with a handshake key. </del> <ins> are encoded as TLS handshake messages, including length and type fields.  They do not include any TLS record layer framing and are not encrypted with a handshake key. </ins> The structures are defined to be:

Discussion:
Proposal to fix Issue
cc NAME
The Introduction limits this to TLS 1.2 and later, but DTLS is similar. Do you want to take that into account now, or ignore it? DTLS has additional fields to support fragmentation: URL URL
Exported authentication are meant to be embedded in a higher-layer protocol, so there's no need to support fragmentation.
The draft states that there should be no "TLS framing" but what is meant is that the handshake messages shouldn't be encapsulated by TLS Record Framing (which does the encryption of the handshake messages).
Change:
additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header <del> fields SEMANTICS. </del> <ins> fields HTTP. </ins> The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from

Discussion:
Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. Duplicate reference: RFC9110, mentioned in 'SEMANTICS', was also mentioned in 'HTTP'.
Change:
where "pk" is the HPKE public key encoded by the collector's HPKE key, "server_role" is "0x02" for the leader and "0x03" for a helper. <ins> The "SealBase()" function is as specified in HPKE for the ciphersuite indicated by the HPKE configuration. </ins> The collector decrypts these aggregate shares using the opposite process.  Specifically, given an encrypted input share, denoted

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:
for protecting header field values that are not to be put at risk by compressing them (see security-considerations for more details). <del> The fourth ("S") bit indicates whether the reference is to the static </del> <ins> The fourth ('T') bit indicates whether the reference is to the static </ins> or dynamic table.  The 4-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header name. <del> When S=1, the number represents the static table index; when S=0, the </del> <ins> When T=1, the number represents the static table index; when T=0, the </ins> number is the relative index of the entry in the dynamic table. Only the header field name is taken from the dynamic table entry; the

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
associated domain of the registration. <del> When registering links to a Resource Directory, the Context refers to the scheme, address, port, and base path for all the links registered on behalf of an endpoint, of the general form scheme://host:port/path/ where the client may explicitly set the scheme and host, and may supply the port and path as optional parameters.  When the context of a registration is explicitly set, the URI resolution rules in RFC3986 MUST be applied. </del> <ins> A Context is a base URL that gives scheme and (typically) authority information about an Endpoint.  The Context of an Endpoint is provided at registration time, and is used by the Resource Directory to resolve relative references inside the registration into absolute URIs. </ins> Commissioning Tool (CT) is a device that assists during the

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
Encrypted Client Hello (ECH), which allows clients to encrypt the entirety of their ClientHello to a supporting server.  This protects the SNI and other potentially sensitive fields, such as the ALPN <del> list. </del> <ins> list.  This extension is only supported with (D)TLS 1.3 RFC8446 and newer versions of the protocol. </ins> 2.

Discussion:
Seeing no pushback on the list, this moves the draft from Experimental to ST.
The design can apply to TLS 1.4 and beyond (presumably).
Done in .
Change:
development.  They included preventing on-path devices from interfering with DNS operations and allowing web applications to access DNS information via existing browser APIs in a safe way <del> consistent with Cross Origin Resource Sharing (CORS) CORS.  There are certainly other uses for this work. </del> <ins> consistent with Cross Origin Resource Sharing (CORS) CORS.  No special effort has been taken to enable or prevent application to other use cases. </ins> 2.

Discussion:
When a statement is so definite, the reader tends to assume that there is something more to be said. In this case, the obvious question is "what other uses are there?", closely followed by "and what reason could the authors have had for not mentioning them?"
Change:
In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat, <del> should use a DNS ID of 0 in every DNS request.  HTTP semantics correlate the request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat. </del> <ins> SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat and the use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

Discussion:
And explain why more clearly.
this is editorial - should me merged imo NAME
I fully disagree that making something a RFC 2119 requirement is "editorial". In this case, it could have surprising effects on the DNS server side of a DOH server. It's worth discussing, but not just sweeping it in with "editorial".
when I wrote that text I meant it to be SHOULD - its a typo; that's why its editorial :) If its not normative then it really has no meaning in that paragraph.