jiebi/CodeConvo huggingface dataset:
Change:
4. This section aims to improve understanding by describing a possible <del> workflow of solutions adhering to the architecture. </del> <ins> workflow of solutions adhering to the architecture.  Note that the section is not normative: it describes only as subset of possible implementations. </ins> 4.1.

Discussion:
There was some concern that section 4 could be seen as normative. To make matters worse, there was some normative text in there. Rework things a bit to address that. Explicitly call out that section 4 is not normative to avoid confusion Move normative text out of 4.3 into 2.1 Add some more description to 4.3 Describe trust for new URIs
Roman writes, It's meant to be informative. Move it Section 2.1 (User Equipment)
We did this in
Benjamin writes, This should be the same as the initial one we received when first accessing the network(e.g. via DHCP, RAs, etc). Perhaps we don't properly indicate elsewhere that this should be supported. I thought we did, but I can't find it... I think we should add a point to Section 2.1 that the UE SHOULD support updates to the captive portal URI from the network provisioning service, and then mention here that that service is what did it. The same trust as mentioned in section 7.1 still applies.
Benjamin writes, Do it.
Change:
min and max values, the vector description simply includes a "V". For example: <del> Such a vector can represent values with length from 0 bytes to 2^62 </del> <ins> Such a vector can represent values with length from 0 bytes to 2^30 </ins> bytes.  The variable-length integer encoding reserves the two most significant bits of the first byte to encode the base 2 logarithm of the integer encoding length in bytes.  The integer value is encoded

Discussion:
The recently introduced variable size encoding allows for very large message sizes that are not practical in any realistic scenario. Since decoders will most likely not allow such large messages anyway, this PR limits the maximum size to 30-bit.
cc NAME who had some thoughts about limits on the last virtual interim.
My general points are: Code defensively Fail gracefully Use the lower level protocol carrying MLS Messages to send a clear and relevant error message if something is too big. Ex: HTTP/2.0 413 Commit.Proposals exceeds 2^16 bytes ex: HTTP/2.0 413 Too many proposals referenced in Commit (>9999)
Change:
used with care or avoided as described in RFC7721. The resulting concatenated name MUST consist only of characters out <del> of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </del> <ins> of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </ins> If the Record has no Unit, the Base Unit is used as the Unit.  Having no Unit and no Base Unit is allowed.

Discussion:
The actually change looks good to me and if we fail to get all the examples correctly generated, don't worry, we can clean that up during WGLC
Change:
also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many <del> use cases. </del> <ins> use cases.  freshness discusses ways in which freshness can be used in this architecture to protect against replay attacks. </ins> To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust,

Discussion:
Based on discussion at IETF about including a very high level summary, and text in the arch docs, draft-birkholz-rats-reference-interaction-model, and draft-birkholz-rats-tuda. Signed-off-by: Dave Thaler
A quick review of the strawman, using the strawman to highlight a few points for discussion.
Change:
The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. <del> For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </del> <ins> For newAccount requests, and for revokeCert requests authenticated by certificate key, there MUST be a "jwk" field.  This field MUST contain the public key corresponding to the private key used to sign the JWS. </ins> <del> For all other requests, there MUST be a "kid" field.  This field must contain the account URL received by POSTing to the new-account resource. </del> <ins> For all other requests, the request is signed using an existing account and there MUST be a "kid" field.  This field MUST contain the account URL received by POSTing to the newAccount resource. </ins> Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET

Discussion:
The example was misleading in case a certificate is revoked by signing the revocation request with the certificate's private key. I assume "jwk" should be the public key from the certificate in this case and not the account key; see URL
Merging because it looks like the issue raised by NAME has been addressed.
Change:
See <del> See Authors' Addresses section. </del> <ins> httpapi@ietf.org or art@ietf.org </ins> See Authors' Addresses section <del> n/a </del> <ins> IESG </ins> 3.

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. <del> Contexts are optional, their use is negotiated on each request stream using registration capsules, see register-capsule and register-no- context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </del> <ins> Contexts are optional, whether to use them or not is decided by the client on each request stream using registration capsules, see register-capsule and register-no-context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more

Discussion:
It doesn't appear that the peer has any say in the allocation of context IDs. If not, they're not really "negotiated." Perhaps better to say that they are "declared" or merge with "allocated."
Change:
handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in <del> QUIC packet headers, except specific parts of Initial packets, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del> <ins> QUIC packets.  Such alterations would cause the integrity check to fail, which results in the receiver discarding the packet.  Some parts of Initial packets could be altered by removing and re-applying the authenticated encryption without immediate discard at the receiver.  However, the cryptographic handshake validates most fields and any modifications in those fields will result in connection establishment failing later on. </ins> 2.6.

Discussion:
This mixes two things: damage to packets that cause integrity protection to fail, and modification of Initial packets. How about:
Change:
in the IANA Named Information Hash Algorithm Registry [1]. If the "hash_method" value is not present in the client instance's <del> request, the algorithm defaults to "sha3-512". </del> <ins> request, the algorithm defaults to "sha-256". </ins> <del> For example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then </del> <ins> For example, the "sha-256" hash method consists of hashing the input string with the 256-bit SHA2 algorithm.  The byte array is then </ins> encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. <del> The "sha2-512" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using </del> <ins> The "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using </ins> URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value.

Discussion:
To edit notification comments on pull requests, go to your .
Nothing more than yaron's feedback
From IETF115 comments: Change the default hash for interaction_hash to sha256, and change the MTI profile to use the same.
Please search for some remaining occurrences of "sha-512".
Change:
This element is OPTIONAL. <del> Implements: </del> <ins> Implements: req-use-delegation, </ins> 4.

Discussion:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.
Change:
Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as Namespace. <del> Namespaces for the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-numbers/ protocol-numbers.xhtml) are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation specific properties. </del> <ins> Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- numbers/protocol-numbers.xhtml), translated to lower-case and with characters other than letters, numbers, and hyphens deleted, are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation-specific properties. </ins> 4.2.2.

Discussion:
Clarify how the IANA protocol numbers registry keywords (largely upper-case) textually relate to Transport Property Names. Refine some of the surrounding text.
Change:
the group can send a Remove proposal followed by a Commit message. The Commit message provides new entropy to all members of the group except the removed member.  This new entropy is added to the epoch <del> secret for the new epoch, so that it is not known to the removed </del> <ins> secret for the new epoch so that it is not known to the removed </ins> member.  Note that this does not necessarily imply that any member is actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism.

Discussion:
Some of these editorial comments I find less clear than the original. The code changes and varint are fine. Could you please split this into two more atomic PRs so we can discuss separately?
Feel free to leave comments on the editorial portion of this PR to keep things moving
Change:
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> IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. </ins>

Discussion:
Addressing
NAME I've bravely stolen some text to meet the additional IANA request.
Resolvers will normally return NXDOMAIN for queries that don't exist, and caches are permitted to treat this as an indication that no records of any type exist at the zone (RFC 8020). That means that it isn't enough for resolvers to synthesize a SVCB response for URL they also have to synthesize a NOERROR response for any other QTYPE on that name. The draft should probably mention that. Credit to NAME for noticing this.
NAME agreed that we could note this, but it's also expected that a client wouldn't be sending out queries for other types on URL, right? In practice, I'm not sure how this would happen.
Yes, but if a cache is shared by multiple clients (be they distinct devices on a network or even distinct apps on a device), a single client could issue a query that causes the shared cache to remember the NXDOMAIN answer. That's a problem whether the source of the query is malicious or just weird.
Fair, so this could be accidental or malicious fallout, not a normal occurrence.
I'd suggest that there should also be a reference to RFC 6303 section 3 - should be considered a "locally resolved domain".
Closed with
Change:
D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media <del> Distributor to establish HBH keys for transmitting RTP and RTCP </del> <ins> Distributor to establish the HBH key for transmitting RTP and RTCP </ins> packets to that peer Media Distributor.  The Key Distributor does not <del> facilitate establishing HBH keys for use between Media Distributors. </del> <ins> facilitate establishing a HBH key for use between Media Distributors. </ins> 4.5.1.

Discussion:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM
Change:
TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible <del> with that version of TLS. </del> <ins> with that version of TLS.  EAP-TLS is typically used with client authentication and typically fragments the TLS flights into a large number of EAP requests and EAP responses.  Resumption significantly reduces the number of round-trips and enables the EAP-TLS server to omit database lookups needed during a full handshake with client authentication. </ins> For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS <del> server, the client can use the PSK identity received in the ticket to negotiate the use of the associated PSK.  If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial </del> <ins> server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial </ins> handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer whether to offer resumption, ut it is RECOMMENDED that the EAP-TLS peer offer

Discussion:
During dicsussion on close_notify, there was a good dicusssion on the list on why resumption is needed. Some short clarifications on how TLS 1.3 works. E.g. that PSK is not included in the ticket.
Change:
section for this media type or in the same bundle group as the first m= section for this media type. <del> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </del> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:

Discussion:
This will happen when applying either an offer or an answer, for consistency. Also, any "semantics verification" failure will now result in an error, which was assumed but not explicitly stated. Fixes issue .
This is a good start, but you'll also want to update 4.1.1, 5.3.1 to reflect this (new) policy. Note though that this will end up being inconsistent with the handling of max-bundle as it is described in 4.1.1, although I still think this is the right approach.
Updated 4.1.1. I thought I already made the needed change to 5.3.1, what else needs to be changed?
I may be overlooking something, but I don't think this behavior is documented anywhere. I think the choices, in order of harshness, are: Silently fails, and you don't get RTCP negotiationneeded fires, and the m= section is port-zeroed in the next offer setRemoteDescription throws an error I'd lean towards the middle option, but that assumes that applications listen to negotiationneeded.
I lean toward the last option, as a violation of an invariant set by the offerer.
Agree that this should be documented somewhere.
+1 on the throw an error option
The general policy that we discussed here in Seattle was that any spec violation should lead to a setRD exception, not a zero port. For the rtcp-mux-only doc, we probably should have some language that makes rtcp-mux in the answer a MUST.
Resolved by
Change:
remote, MUST indicate support for the following specifications.  If any of these are absent, this omission MUST be treated as an error. <del> Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP profile, as specified in RFC5764, MUST be used. </del> ICE, as specified in RFC5245, MUST be used.  Note that the remote endpoint may use a Lite implementation; implementations MUST properly handle remote endpoints which do ICE-Lite. DTLS-SRTP, as specified in RFC5763, MUST be used. <ins> 5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer. For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP endpoints MUST follow the following rules when processing the media m= sections in an offer: The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. Any profile matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e. a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the "UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. </ins> 5.2. When createOffer is called, a new SDP description must be created

Discussion:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm
Change:
indicated ID if these requests were not processed. If a server receives a GOAWAY frame after having promised pushes <del> with a Push ID greater than or equal to the identifier received in a GOAWAY frame, those pushes will not be accepted. </del> <ins> with a Push ID greater than or equal to the identifier contained in the GOAWAY frame, those pushes will not be accepted. </ins> Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the

Discussion:
Ambiguous description with for user agents in : It'd be better to remove or clarify rather than ambiguously allowing user agents with . A bit misleading expression with in This sentence looks to readers like that clients MAY send same requests on another connection even when the server keeps canceling or something regardless of clients' requests. There should be additional sentences no matter if it's the expected behavior or not. Some phrases in look verbose and confusingThe link in is wrong: should be replaced with .
These are separate issues, so let's look at them separately: This is deliberately vague, and the reason is explicitly stated. They don't affect the operation of the protocol, but user agents are allowed to make use of the associations in implementation-specific ways. This reflects HTTP/2, where some browsers use the association and some do not. Here again, I'm not seeing the problem. The requests have been canceled -- effectively "unsent" on this connection. If the client still needs to make those requests, they can't send them on this connection, but they MAY open a new connection. "received in a" -> "contained in the" would help here, unless you had a suggestion for making it tighter. The final issue is unrelated to these drafts, and is something the Tools server does. If you see an incorrect reference in the text draft or Editor's Copy HTML, please do point them out.