jiebi/CodeConvo huggingface dataset:
Change:
forwarding by intermediary nodes. The server SHALL include a new Partial IV in responses (with or <del> without the Observe option) to Observe registrations. </del> <ins> without the Observe option) to Observe registrations, except for the first response where Partial IV MAY be omitted. </ins> RFC7252 does not specify how the server should act upon receiving the same Token in different requests.  When using OSCORE, the server

Discussion:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
server.  It SHOULD retry the handshake with a new transport connection, using the retry configurations supplied by the server. The retry configurations may only be applied to the retry connection. <del> The client MUST continue to use the previously-advertised configurations for subsequent connections.  This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </del> <ins> The client MUST NOT use retry configurations for connections beyond the retry.  This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </ins> If none of the values provided in "retry_configs" contains a supported version, the client can regard ECH as securely disabled by

Discussion:
When retry-configs are defined in section 5 we say they are for "subsequent connection attempts" but in 6.1.6 we have a MUST NOT for using those for "subsequent connections." That seems inconsistent and maybe even wrong if one thinks about how e.g. wget can crawl web pages, or how applications might use libcurl, so this change tries to fix that. Not sure if short duration is the right way to phrase it though.
Change:
encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client. <ins> The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers.  The intent of the SUDN is to allow clients to communicate with the Unencrypted Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication.  For more context, see the rationale behind "ipv4only.arpa" in RFC8880. </ins>

Discussion:
This addresses the remaining portions of not address by a prior PR
Migrated from original DEER issue: URL
The Special Use Domain Name (SUDN) URL needs more clarification. Specifically: Queries against the .arpa nameservers The draft should mention that .arpa is a delegated zone, currently served by the root nameservers. Clients that query a resolver that is unaware of this requirement will "leak" queries to the root nameservers. When URL is not present in a resolver configuration Section 6.1 discusses how a forwarder should behave and suggests that results should not be cached other than for Equivalent Encrypted Resolvers under their control. How is that determined? There is no discussion around a non-forwarding resolver's behaviour. Should it return NODATA? Forwarding queries to URL will attempt to attach a client to an upstream resource's equivalent resolver. If that equivalent resolver's cert doesn't include the forwarder, the client must reject the answer. Is it not therefore the case that the forwarder caching behaviour is irrelevant? All valid responses to this query must be equivalent to the forwarder itself. When URL is present in a resolver configuration I would suggest some clarification wording something like this: The expectation is that this record set will detail equivalent resolvers. A client that chooses not to interact with any of these equivalent resolvers SHOULD continue to use the unencrypted resolver, honouring the SVCB TTL. When the SVCB TTL expires, the client may choose to re-query in an attempt to discover newly available equivalents. I would suggest (prefer?) changing the SUDN behaviour so that queries against it are never sent upstream. Resolvers (and forwarders) that do not have a configured URL RRset should return NODATA. This would mean that URL SUDN RRsets are always specific to the IP queried.
It may be good to model the advice after RFC8880, which defines URL
I am leaving this open so I can re-review the text after addressing other PRs; PR 14 addressed some of the points raised in this issue but not all of them.
Change:
known directly by the agent for its own candidate. The Initiator performs the ordinary checks on receiving the candidate <del> information from the Peer (responder) and having formed the checklists.  On the other hand the responding agent either performs the triggered or ordinary checks as described above. </del> <ins> information from the Peer (responder) and having formed the check lists.  On the other hand the responding agent either performs the triggered or ordinary checks as described above. </ins> 5.2.

Discussion:
Removal of timer Tc. Instead timer Ta is used to trigger connectivity checks. Whenever Ta fires, one check list is selected, and a connectivity check is performed for a candidate pair within that check list.
Change:
local policy is configured to trust this IdP domain for the domain portion of the identity string. <del> Sites that have identities that do not fit into the RFC822 style (for instance, identifiers that are simple numeric values, or values that contain '@' characters) SHOULD convert them to this form by escaping illegal characters and appending their IdP domain (e.g., user%40133@identity.example.com), thus ensuring that they are authoritative for the identity. </del> <ins> Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in Section 2.1 of RFC3986.  Characters other than "@" and "%" MUST NOT be percent-encoded.  For example, with a user of "user@133" and a domain of "identity.example.com", the resulting string will be encoded as "user%40133@identity.example.com". Implementations are cautioned to take care when displaying user identities containing escaped "@" characters.  If such characters are unescaped prior to display, implementations MUST distinguish between the domain of the IdP proxy and any domain that might be implied by the portion of the <user> portion that appears after the escaped "@" sign. </ins> 9.

Discussion:
NAME I think this one is good to merge.
Raised by Jim Spring at the interim
I think this is now closed by MT's revision with LOGINNEEDED.
Closing. Jim, please re-open if you believe it is not.
LGTM
Change:
the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. <del> The load balancer decrypts the server ID using 128-bit AES Electronic Codebook (ECB) mode, much like QUIC header protection.  The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the encrypted server id. server_id = encrypted_server_id ^ AES-ECB(key, padded-nonce) For example, if the nonce length is 10 octets and the server ID length is 2 octets, the connection ID can be as small as 13 octets. The load balancer uses the the second through eleventh of the connection ID for the nonce, zero-pads it to 16 octets using the first 6 octets of the token, and uses this to decrypt the server ID in the twelfth and thirteenth octet. The output of the decryption is the server ID that the load balancer uses for routing. 4.3.3. When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID beyond the nonce and server ID.  The nonce and additional bits MAY encode additional information, but SHOULD appear essentially random to observers. The server decrypts the server ID using 128-bit AES Electronic Codebook (ECB) mode, much like QUIC header protection.  The nonce octets are zero-padded to 16 octets using the as many of the first octets of the token as necessary.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the server id. encrypted_server_id = server_id ^ AES-ECB(key, padded-nonce) 4.4. The Triple Stream Cipher CID algorithm is a variant of the stream cipher algorithm stream-cipher-cid-algorithm that provides true cryptographic protection and also mitigates the malleability issues with a simple stream cipher application.  The CID format is the the same as depicted in stream-cipher-cid-format. 4.4.1. The configuration agent actions are the same as in stream-cipher-cid- format-configuration. 4.4.2. Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. </del> The load balancer decrypts the nonce and the server ID using the following three pass algorithm:

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
acceptable to not support migrations of active QUIC connections that are not visible to the network functions performing the DDoS detection.  As soon as the connection blocking is detected by the <del> client, the client may be able to rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </del> <ins> client, the client may be able to rely on the 0-RTT session resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </ins> Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS

Discussion:
Section 4.7 of the manageability draft needs a reference to the fast resumption mechanism.
this s 0-RTT session resumption as explained early in the doc and respectively referred there to the QUIC spec. Would it help to change "fast resumption" to "0-RTT session resumption"?
I think so.
where was in the document 0-RTT session resumption explained? I might have missed it.
He have separate figures for that in the handshake section
However it seems we use the term "0-RTT connection resumption" there so, we should probably do a s/connection/session/ there as well.
Change:
In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept.  In TLS 1.3 the former is expressed by sending <del> the "signature_algorithms" extension.  The latter is expressed by sending the "certificate_authorities" extension (see certificate- authorities). </del> <ins> the "signature_algorithms" and "signature_algorithms_cert" extensions.  The latter is expressed by sending the "certificate_authorities" extension (see certificate-authorities). </ins> Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY

Discussion:
In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.
Change:
merge outstanding pull requests. Editors SHOULD create a new Internet-Draft submission two weeks prior <del> to every session (see Section 7.1 of RFC2418).  Though discussion could use the current version of a document from version control, participants in a session can't be expected to monitor changes to documents in real-time; a published Internet-Draft ensures that there is a common, stable state that is known to all participants. </del> <ins> to every session, which includes IETF meetings, other in-person meetings, and telephone or video conferences (see Section 7.1 of RFC2418).  Though discussion could use the current version of a document from version control, participants in a session can't be expected to monitor changes to documents in real-time; a published Internet-Draft ensures that there is a common, stable state that is known to all participants. </ins> Revisions used to generate documents that are submitted as Internet- Drafts SHOULD be tagged in repositories to provide a record of

Discussion:
This has two commits: Unpack "session" a little more to make it clear that this isn't just IETF meetings. Explain that participation on GitHub isn't the only possible input, and the effect that this has on assessing WG consensus.
Change:
IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for <del> the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions are executed (e.g., </del> <ins> the AC, then packet MUST be dropped.  If there is a matching TSN Stream, then the Stream ID specific TSN functions are executed (e.g., </ins> ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup may also be used for local MAC address learning.

Discussion:
Adding commas, the editor will probably catch these.
Hi Don, many thanks for the review. Cheers Bala'zs
Change:
Added TLS 1.2 to references. Moved RFC 4492 authors to acknowledgements. Removed list of required reading for ECC. <ins> Prepended "TLS" to the names of the three registries defined in the IANA Considerations section. </ins>

Discussion:
if both draft-ietf-tls-iana-registry-updates and this draft add TLS to the registry names then all the registry will have a consistent naming scheme.
Ship it
Shipped
LGTM
Change:
Specify a Local Endpoint using a STUN server: <del> Specify a Local Endpoint using a Any-Source Multicast group to join </del> <ins> Specify a Local Endpoint using an Any-Source Multicast group to join </ins> on a named local interface: Source-Specific Multicast requires setting both a Local and Remote

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.
Change:
For final authorizations, it contains the challenges that were successfully completed. <ins> For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard prefix this field MUST be present, and true. </ins> The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the <del> first label) MUST NOT be included in authorization objects. </del> <ins> first label) MUST NOT be included in authorization objects.  If an authorization object conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix then the optional authorizations "wildcard" field MUST be present with a value of true. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.

Discussion:
requests are allowed to send DNS type identifiers with a value that contains a wildcard prefix ('') as the leftmost label. The authorization object created for the wildcard identifiers in the requests are not allowed to carry the wildcard prefix in the authorization identifier per spec language: This is sensible because the authorization is not for the logical wildcard but for the specific base domain. This leaves an ambiguous situation for client developers/users. Imagine a situation where a user requests a new order with the following request body: It's possible two authorizations will be created for this case, but both will contain the identifier . This can be confusing to users! (e.g. shred/acme4j) If one of the authorizations fails a challenge validation operation the client can't know whether it was the "URL" validation, or the "URL" validation that failed and won't be able to prompt the user to retry with the failed domain removed. Generally speaking it makes presenting accurate error information difficult without over-fitting Let's Encrypt's particular Wildcard issuance policies. (E.g. see discussion in URL and URL) This commit introduces an optional boolean authorization field that can be used to indicate the authorization's identifier should be considered the base domain of a wildcard identifier that was requested. This replaces , which included the baggage of .
Change:
4.2.2. <ins> The "primary" section records a single URL identifying the primary URL of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. 4.2.3. </ins> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself.

Discussion:
Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL
Change:
policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to appraise the trustworthiness of that manufacturer's devices.  Such <del> trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The Trust Anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. </del> <ins> trust is expressed by storing one or more trust anchors in the Verifier's trust anchor store. </ins> In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for

Discussion:
Also add a brief security considerations section, based on text from the TEEP architecture draft. Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
Change:
key_share (see key-share) <ins> In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite.  This allows the client to avoid having to compute partial hash transcripts for multiple hashes in the second ClientHello.  A client which receives a cipher suite that was not offered MUST abort the handshake.  Servers MUST ensure that they negotiate the same cipher suite when receiving a conformant updated ClientHello (if the server selects the cipher suite as the first step in the negotiation, then this will happen automatically).  Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert. </ins> 4.2. A number of TLS messages contain tag-length-value encoded extensions

Discussion:
client to implement because it knows what hash the server will select. Also clarify the language about HRR and Key Shares.
NAME is this what you had in mind?
I did consider bogus binders, but dropping seems more sensible, and it seems like the only impact of the bogus binder would be that if the server didn't follow a consistent rule, then you would get a handshake failure at the server. It's not like it could pick them in any case.
(Agreed. This version feels way less weird.)
NAME comments welcome
Change:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-25 - Add the header to additional data (*) Minor clarifications. IANA cleanup. </ins> draft-24 Require that CH2 have version 0303 (*)

Discussion:
Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL
Change:
media is implicit. This document proposes a simple HTTP based protocol that will allow <del> WebRTC based ingest of content into streaming servics and/or CDNs. </del> <ins> WebRTC based ingest of content into streaming services and/or CDNs. </ins> 1.

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.