jiebi/CodeConvo huggingface dataset:
Change:
Endpoints use transport parameters to authenticate the negotiation of connection IDs during the handshake; see cid-auth. <del> Application Layer Protocol Negotiation (ALPN; see ALPN) allows </del> <ins> Application-Layer Protocol Negotiation (ALPN; see ALPN) allows </ins> clients to offer multiple application protocols during connection establishment.  The transport parameters that a client includes during the handshake apply to all application protocols that the

Discussion:
as well as other instances of the term. RFC 7301 does indeed hyphenate (and that's correct, since "application-layer" is being used as a single unit to describe "protocol").
URL says the registry is
Change:
7.4. <del> If a client decides to cache the certificate chain and re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. </del> <ins> If a peer decides to cache the certificate chain and re-validate it when resuming a connection, they SHOULD also cache the associated delegated credential and re-validate it.  Failing to do so may result in resuming connections for which the DC has expired. </ins> 7.5.

Discussion:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.
Change:
aborted the Connection; however, there is no guarantee that an abort will be signaled: <ins> A SoftError can inform the application about the receipt of an ICMP error message that does not force termination of the connection, if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </ins> 11. RFC-EDITOR: Please remove this section before publication.

Discussion:
TEXT: informed when an ICMP error message arrives. I think this is OK. but is this intended to be for soft-errors, since hard-errors break the connection? I think I get this, although some transports obvioulsy "eat" the ICMP packets they receive, and many ICMP messages have no meaning to an app, but some can be important. Tell me more please...
this comes from minset - and so it’s based on the rfc “soft error” text. true, no guarantee that you get it.
So, maybe the next rev of text should just say this and it will be fine.
Change:
This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252. <ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP. </ins> A Block1 or Block2 option that includes an SZX value of 7.

Discussion:
Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports. Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.
See also
I would add a note to the terminology section that CoAP over reliable transports refers to stream-based transport protocols, such as TCP.
Sounds reasonable: The term "reliable transport" only refers to stream-based transport protocols such as TCP.
URL The term "reliable transport" only refers to stream-based transport protocols such as TCP. We could say more explicitly: sequenced/order-preserving, reliable... (Stream might be byte stream or message stream.) s/only refers/is used only to refer/
NAME - I would probably avoid "sequenced" which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability. Perhaps too much detail? How about: The term "reliable transport" is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte-stream.
NAME wrote: This concisely clarifies my initial concern, and I'm ok with this.
Change:
connections.  This list can be passed to a peer via a signalling protocol, such as SIP or WebRTC, to configure the remote. <del> [NOTE: This API is sufficient for TCP-style simultaneous open, but should be considered experimental for ICE-like protocols.] </del> 6.4. Groups of Connections can be created using Clone action:

Discussion:
There are still a few s and similar scattered throughout the document. Find them and fix them, or move them to post-London issues.
Change:
Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- adopted timestamp format, which forms the basis of RFC3339.  However, <del> this format doesn't allow timestamps to contain any additional relevant information, which means that any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </del> <ins> this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </ins> This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and <del> compositeattester.  Other examples may exist, and the examples </del> <ins> compositedevice.  Other examples may exist, and the examples </ins> discussed could even be combined into even more complex implementations.

Discussion:
This changes may of the Composite Attester->Composite Device. It updates the diagram a bit, but it does not go as far as . The terms "lead Attester" are retained, but not as new term ("lead", not "Lead"). The Attesting Environment is not pluralized.
Change:
updating maintenance options. Termination (termination) focuses on the methods by which data <del> transmission is stopped, and state is torn down in the transport. </del> <ins> transmission is stopped, and connection state is torn down. </ins> The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object.  Note that some

Discussion:
/transport/ should be /connection state/
This resolves one small part of Zahed's review.
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM
Change:
observers.  The offset of the packet number can be decoded in long headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is <del> cryptographically obfuscated. </del> <ins> cryptographically protected. </ins> key phase: The Key Phase bit, present in short headers, specifies the keys used to encrypt the packet to support key rotation.  The <del> Key Phase bit is cryptographically obfuscated. </del> <ins> Key Phase bit is cryptographically protected. </ins> 2.2.

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
indicated by a link-format content-format.  Sub-topics are also topics and may have their own sub-topics, forming a tree structure of unique paths that is implemented using URIs.  The full URI of a topic <del> includes a schems and authority for the Broker, for example </del> <ins> includes a scheme and authority for the Broker, for example </ins> "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". 3.5.

Discussion:
This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).
Change:
7.2. <del> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. </del> <ins> The solution described here requires that when the User Equipment needs to access the API server, the User Equipment authenticates the server; see section_client. </ins> The Captive Portal API URI might change during the Captive Portal Session.  The User Equipment can apply the same trust mechanisms to

Discussion:
A reviewer pointed out that we need to specify how TLS is used. Link to the existing procedure in the User Equipment requirements. Also rephrase so that it doesn't sound like we're suggestion that using TLS is optional.
I'm not sure if my 'link' is a good idea. I could just repeat the procedure verbatim, I suppose, but it seems like a waste of text.
Benjamin writes While in here, Roland writes:
This looks fine, but it might be more concise.
Change:
If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the <del> Unencrypted DNS Resolver. </del> <ins> Unencrypted DNS Resolver, so as to prefer Encrypted DNS whenever possible. </ins> If these checks fail, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB <del> record's Time to Live (TTL). </del> <ins> record's Time to Live (TTL) in order to avoid excessive queries that will lead to further failed validations. </ins> If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
A signed object describing a client's identity and capabilities, and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg- <del> hpke) public key that can be used to encrypt to that client. A key package that is prepublished by a client, which other clients can use to introduce the client to a new group. </del> <ins> hpke) public key that can be used to encrypt to that client, and which other clients can use to introduce the client to a new group. </ins> A signing key pair used to authenticate the sender of a message.

Discussion:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Change:
an authenticator <del> It returns the certificate chain and extensions and a status to indicate whether the authenticator is valid or not.  If the authenticator was empty - that is, it did not contain a certificate - the certificate chain will contain no certificates.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Well-formed empty authenticators are returned as valid. </del> <ins> It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is valid or not.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator.  Well-formed empty authenticators are returned as valid. </ins> 8.

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
A TSN-aware MPLS (DetNet) node implementations MUST support the Sequencing function and the Sequence encode/decode function as <del> defined in IEEE8021CB if FRER is used inside the TSN sub-network. </del> <ins> defined in Clause 7.4 and 7.6 of IEEE8021CB if FRER is used inside the TSN sub-network. </ins> The Sequence encode/decode function MUST support the Redundancy tag (R-TAG) format as per Clause 7.8 of IEEE8021CB. A TSN-aware MPLS (DetNet) node implementations MUST support the Stream splitting function and the Individual recovery function as <del> defined in IEEE8021CB when the node is a replication or elimination point for FRER. </del> <ins> defined in Clause 7.7 and 7.5 of IEEE8021CB when the node is a replication or elimination point for FRER. </ins> 4.3. TSN Streams supporting DetNet flows may use Frame Replication and <del> Elimination for Redundancy (FRER) as defined in IEEE8021CB based on the loss service requirements of the TSN Stream, which is derived from the DetNet service requirements of the DetNet mapped flow.  The specific operation of FRER is not modified by the use of DetNet and follows IEEE8021CB. </del> <ins> Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE8021CB based on the loss service requirements of the TSN Stream, which is derived from the DetNet service requirements of the DetNet mapped flow.  The specific operation of FRER is not modified by the use of DetNet and follows IEEE8021CB. </ins> FRER function and the provided service recovery is available only within the TSN sub-network as the TSN Stream-ID and the TSN sequence

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
IXDTF strings such as: are internally inconsistent, as Europe/Paris does not use a time zone <del> offset of 0 (which is indicated in the "Z", an abbreviation for "+00:00"), nor a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </del> <ins> offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </ins> Similar with: <del> However, </del> <ins> (assuming that the recipient does not understand the suffix key "knort"). </ins> <del> all have an internal inconsistency or an unrecognized suffix key/ value, so a recipient MUST treat the IXDTF string as erroneous. </del> <ins> In contrast to this elective use of a suffix tag, each have an internal inconsistency or an unrecognized suffix key/ value that are marked as critical, so a recipient MUST treat the IXDTF string as erroneous. </ins> Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <del> The server MUST also provide a link relation header field with relation "author" to indicate the order under which this certificate was issued. If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was submitted to a CT log.  An SCT can be included as an extension in the certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation "ct-sct". </del> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.

Discussion:
As they are all fulfilled by the endpoint and are unnecessary. The relation is removed as the SCT will be provided by the CA via the certificate or a OCSP response, if it doesn't provide these then the client should be able to retrieve the SCT itself from the logs it expects to find the certificate in (or submit it itself). Also removes a paragraph about Certificate Transparency from the 'Downloading the Certificate' section as it is irrelevant to the section and discusses operations of the CA unrelated to the ACME protocol. Additionally changes the relation which is not registered with a URI extension using the ACME URN namespace .
Looks good. Was posted on the list two weeks ago, with no objections, so merging.
Change:
Servers MUST NOT generate new connection IDs using an old configuration after receiving a new one from the configuration agent. <del> Servers MUST send NEW_CONNECTION_ID frames that provide CIDS using </del> <ins> Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using </ins> the new configuration, and retire CIDs using the old configuration using the "Retire Prior To" field of that frame. <ins> It also possible to use these bits for more long-lived distinction of different configurations, but this has privacy implications (see multiple-configs). </ins> 3.2. If a server has not received a valid QUIC-LB configuration, and believes that low-state, Connection-ID aware load balancers are in the path, it SHOULD generate connection IDs with the config rotation <del> bits set to '11' and SHOULD use the "disable_migration" transport parameter in all new QUIC connections.  It SHOULD NOT send </del> <ins> bits set to '11' and SHOULD use the "disable_active_migration" transport parameter in all new QUIC connections.  It SHOULD NOT send </ins> NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits

Discussion:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.
Change:
Section 4.1.3).  These mechanisms do not interfere because the backend server only signals ECH acceptance in TLS 1.3 or higher. <del> 10.8. </del> <ins> 10.9. </ins> RFC8744 lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ECH design against them. <del> 10.8.1. </del> <ins> 10.9.1. </ins> Since servers process either ClientHelloInner or ClientHelloOuter, and because ClientHelloInner.random is encrypted, it is not possible for an attacker to "cut and paste" the ECH value in a different Client Hello and learn information from ClientHelloInner. <del> 10.8.2. </del> <ins> 10.9.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)