jiebi/CodeConvo huggingface dataset:
Change:
12. <ins> changes in this branch Large rework of section 7 (Security policies) Rather than prescribing which data in the RD _is_ authenticated (and how), it now describes what applications built on an RD _can_ choose to authenticate, show possibilities on how to do it and outline what it means for clients. This addresses Russ' Genart review points on details in the text in a rather broad fashion.  That is because the discussion on the topic inside the WG showed that that text on security has been driven more review-by-review than by the an architectural plan of the authors and WG. Add concrete suggestions (twice as long as registrant number with retries, or UUIDs without) for random endpoint names </ins> changes from -23 to -24 Discovery using DNS-SD added again

Discussion:
This is the WIP work to go from "we explain how exactly to do RD security" (and get the details wrong) to "we outline what needs to be considered but it's really up to the application" talked about in URL
(as no single commit has this in its metadata)
From Russ's Genart review: It's tempting to say "squared number of maximum endpoints times security" here. But really what's the error mode here? If a registrant happens to pick something duplicate, it'll get a 4.03 Forbidden. It could then try a different value, but as the RD only "can" (and not MUST) check for collisions, it might have allowed someone else to take our registrant's ep name, and if the registrant was previously successful with that name, it can't change it any more as the RD would refuse it based on the MUST. We can make both MUSTs (the RD already needs to keep a list of used certificates already anyway, it only adds a requirement to use it (possibly via a new index)), but then still, what's a device to do if it receives a 4.03? Change its ep name as this is obviously not the same RD where it had worked before? Just fail? Can or must a device change its name if it is fashioned with a new certificate? Does it need to know the RD's criteria for equivalence of certificates to decide that?
With the text of f98deeee7bd603c7e6b4da2b9936d45a99e18ceb this is easier now (as the error mode in "and require the same properties" is implied to be 4.01); text to follow.
Change:
While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD <del> therefore accept URIs of all schemes they support, both in absolute and relative forms, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </del> <ins> therefore accept URIs of all schemes they support, both as URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </ins> The URI Discovery operation can yield multiple URIs of a given resource type.  The client can use any of the discovered addresses

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
Sent by servers when a client certificate is desired but none was provided by the client. <ins> Sent by servers when a client advertises protocols that the server does not support. </ins> New Alert values are assigned by IANA as described in iana- considerations.

Discussion:
RFC 7301 defines the ALPN extension and defined a new alert "noapplicationprotocol". TLS 1.3 uses ALPN but currently misses the alert in Section 6.
URL You also need to add it to the Error Alerts section with a description.
Change:
TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC2434.  Values with the first byte 255 (decimal) are reserved <del> for Private Use RFC2434.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. [[TODO: How to denote that values ending in 0x00 through 0x03 are also reserved?]] </del> <ins> for Private Use RFC2434.  Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. </ins> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in

Discussion:
Avoid both starting with an existing hash AND ending with an existing SignatureAlgorithm. In principle, this should not be necessary, but TLS says: Bouncy Castle appears to have been enforcing this, causing interop issues. As this was a straight-up MUST NOT, it seems prudent to renumber. And if we're renumbering anyway, may as well avoid all the old SignatureAlgorithms and avoid confusing tools like Wireshark.
Change:
other certificate management functions, such as certificate revocation. <del> DANGER: Do not implement this specification.  It has a known signature reuse vulnerability.  For details, see the following discussion: </del> <ins> DISCLAIMER: This is a WIP draft of ACME and has not yet had a thorough security analysis. </ins> <del> https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf- 4Yc </del> <ins> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1].  Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). </ins> 1.

Discussion:
It's no longer at a "do not implement" stage, but some caution is still merited. Also, it's good to have a pointer in the draft to this repo. (Cribbed from the TLS 1.3 spec.)
Change:
This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <del> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </del> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].

Discussion:
In the introduction, it says "Reliability within QUIC is performed on a per-stream basis, so some frame types are not eligible for retransmission" Is it really per-stream? Some frames are retransmitted even though they aren't associated with a stream. Really, the detection mechanism is packet-based, the retransmission decision is made on a per-frame basis, and for stream-specific frames there is the added consideration of stream state (i.e. do not resend if reset) I suggest replacing the sentence above with "Some QUIC frame types are not eligible for retransmission."
Do you have examples? It's common for an action to be attempted again, but not for the frame to be retransmitted. That's not quite right. QUIC does not retransmit stream frames, it instead looks at stream state to see what data needs to be retransmitted - there's an important conceptual difference there: let's say you had 100 bytes left in your packet and therefore sent 98 bytes of stream data and that got lost but now you have a full 1200 payload available, you shouldn't retransmit that 100 byte STREAM frame and instead create a new STREAM frame with as much data as you want to send. states:
So I agree with everything you're saying factually; this is an editorial, semantic gripe about what it means that reliability is on a per-stream basis and what it means that a frame is retransmitted. It's true that, for example, MAX_DATA frames aren't resent verbatim, but RFC 9000 addresses them in a section called "retransmission of information" due to the common-sense meaning of the term. What are you trying to communicate by saying that reliability is "on a per-stream basis"?
I agree that this sentence is confusing. Perhaps we just remove it entirely? NAME NAME thoughts?
NAME NAME made a proposal with
LGTM modulo one commentLGTM
Change:
Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit <del> to or requirement on the places that an Attesting Environment can exist, but they typically are in Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware.  An execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed to be capable of claims collection are referred to in this document as Attesting Environments. </del> <ins> to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 3.4.

Discussion:
Why not? What’s the message you want to convey here? What would disqualify an execution environment from being capable of claims collection? How would you know if an Execution Environment is an Attesting Environment?
What does it mean to be capable of claims collection? If this example had a TPM, then this function would be entirely inside the TPM, no?
subsequent line now reads: ` Should this explicitely say, "TPM" as well, or is that implied?
Change:
If the server supports wildcard names, it SHOULD set this value to 260. <del> The moment when the keys become valid for use.  The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not including leap seconds. The moment when the keys become invalid.  Uses the same unit as not_before. </del> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in RFC8446; Section 4.2.  The purpose of the field is to provide room

Discussion:
We now have a proper retry mechanism, so we don't need to prevent clients to connect using expired keys anymore.
NAME notes that the notbefore and notafter fields are there and described, but not really part of the operational notes. Having something there that talks about these, particularly as it relates to clock skew, would be valuable.
(My ~monthly login into URL - this'd be better on the TLS WG list, and I will send mail on this sometime but anyway...) The not-before and not-after fields are a mistake. Same as turned out true for x.509. I was just doing testing where FF nightly barfed on ESNIKeys I'd published for only that non-reason. (There is no overall security win in so-doing, in general.) Creating a tangle between the cadence at which one updates DNS, the ESNIKeys-internal "lifetime" of a key, the DNS TTL and server-state is basically just pointless nonsense. Let's delete those fields from ESNIKeys before we're done and just rely on DNS for what it already does.
Now that has been merged, I agree that there is less need for notbefore and notafter fields. Previously, a client using an expired key led to connection failure, and therefore having these fields were necessary.
Fixed by removing these fields with .
Thank you for the PR. LGTM
Change:
to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR." <del> This approach maps badly to a pre-defined enum.  As such, we define the crypto_error string as having a dynamic component here, which should include the hex-encoded and zero-padded value of the TLS alert description. </del> <ins> This approach maps badly to a pre-defined enum.  As such, the crypto_error string is defined as having a dynamic component here, which should include the hex-encoded and zero-padded value of the TLS alert description. </ins> 9.

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senmlx and sensmlx </ins> Macintosh file type code(s): none

Discussion:
Why is there no sensml+cbor? (I can't really find where sensml+json is actually defined.) Is that really TODO?
sensml+json is defined in "Multiple Datapoints". Perhaps could be improved. That TODO was fixed in URL
That is an example, no? Where is the definition?
(In CBOR, SensML would just be a CBOR sequence. No need even for an array around that.) See also RFC 7464...
Change:
setup. When setLocalDescription is eventually called and the JSEP <del> implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the </del> <ins> implementation prepares to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the </ins> application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components are used or because the pool has not had enough time to

Discussion:
use 'prepares to gather' instead of 'goes to gather', removed comments, issue 9
9) [rfced] We suggest clarifying "goes to gather" - perhaps "gathers", "starts to gather", "prepares to gather", etc. "goes to gather" may be confusing for some readers. Original: When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.
'prepares to gather' seems like the right choice.
NAME please close this issue once you consider it resolved.
Change:
1.2. <del> Captive Network: A network which limits communication of attached </del> <ins> Captive Portal: A network which limits communication of attached </ins> devices to restricted hosts until the user has satisfied Captive Portal Conditions, after which access is permitted to a wider set of hosts (typically the Internet).

Discussion:
A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal aligns more closely with familiar use of the term. Further, other documents such as the API draft refer to the system as a whole as a Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash writes: I think that this is clear: one is a network and the other a server. Review to see if the right choice is used throughout. URL point out that we assume a degree of mutual control over both.
Change:
applies for encrypted data sent to an unauthenticated party.  In particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error messages.  Using the same EAD_1 in several EDHOC sessions allows <del> passive eavesdroppers to correlate the different sessions.  Another consideration is that the list of supported cipher suites may potentially be used to identify the application.  The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. </del> <ins> passive eavesdroppers to correlate the different sessions.  Note that even if ead_value is encrypted outside of EDHOC, the ead_label in EAD_1 is revealed to passive attackers and the ead_label in EAD_2 is revealed to active attackers.  Another consideration is that the list of supported cipher suites may potentially be used to identify the application.  The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. </ins> An attacker observing network traffic may use connection identifiers sent in clear in EDHOC or the subsequent application protocol to

Discussion:
The current text just says that: "The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information. This also applies for encrypted data sent to an unauthenticated party. In particular, it applies to EAD1, IDCREDR, EAD2, and error messages. " The eadvalue is expected to sometimes/often be encrypted outside of EDHOC. The text should be augmented with text that eadlabel leaks information even if ead_value is encrypted outside of EDHOC.
Change:
If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert. <del> An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion of greater than 255 bytes.  An endpoint that receives a record from its </del> <ins> An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets.  An endpoint that receives a record from its </ins> peer with TLSCipherText.length larger than 2^14 + 256 octets MUST terminate the connection with a "record_overflow" alert.  This limit is derived from the maximum TLSPlaintext length of 2^14 octets + 1

Discussion:
I forsee some merge conflicts in the future, as there's already and I have plans to rototill this section a bit more than you do here.
This won't conflict with . Git is good at detecting identical changes.
Change:
cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards <del> Track document RFC8126 is required to register a cipher suite with the value "Yes". </del> <ins> Track document RFC8126 is REQUIRED to register a cipher suite with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites

Discussion:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .
Change:
<del> Value of the negotiated CID. </del> <ins> The DTLSCiphertext.cid value. </ins> <del> 1 byte field indicating the length of the negotiated CID. </del> <ins> 1 byte field indicating the length of the DTLSCiphertext.cid. </ins> All other fields are as defined in the cited documents.

Discussion:
Addresses URL
Thanks! This PR clarifies the used cid value.
In my opinion, it's the actual cid on the record header, not the negotiated cid, even if both are intended to be the same. Therefore it is . Or has this changed? Is the MAC now extended by the negotiated CID?
Fixed with
Change:
analysis and padding, or migration might be relevant for other applications using QUIC as well. <del> 14. </del> <ins> 15. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Discussion:
(hopefully)
okay, next try. Moved some text to applicability and rewrote stuff in manageability... please review again...
Discussion in closed PR
Change:
Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes. <ins> As with the "coap" and "coaps" schemes defined in RFC7252, all URI schemes defined in this section also support the path prefix "/.well- known/" defined by RFC5785 for "well-known locations" in the namespace of a host.  This enables discovery as per Section 7 of RFC7252. </ins> 7.1. The "coap+tcp" URI scheme identifies CoAP resources that are intended

Discussion:
RFC 7252 says about : in Section 6.1 of RFC 7252; it is maybe an erratum that we didn’t do the same in Section 6.2. In any case, we need to do this for all the new URI schemes we define in the current spec, probably best by a blanket statement for all of them at the start of section 7.
RFC 7252 Section 6.2 specifies support for .well-known paths by saying All of the requirements listed above for the "coap" scheme are also requirements for the "coaps" scheme [...] At least that's the intention.
OK, it is not clear that extending is a "requirement", so to me this is at least a "hold for document update" style erratum for RFC 7252. But it is good that the right intention is in there, even if not unambiguously said so.
Change:
can always support this property, but once a Message has been sent into the send buffer of a protocol, only certain protocols may support removing a message.  For example, an implementation cannot <del> cannot remove bytes from a TCP send buffer, while it can remove data from a SCTP send buffer using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this property may be ignored. </del> <ins> remove bytes from a TCP send buffer, while it can remove data from a SCTP send buffer using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this property may be ignored. </ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering

Discussion:
I also added a link to NEATPy in the overview of implementations, and inserted a missing word in interface (a missing "without", must have been a nit)
It might be worth to better align the sections on Message Properties in the API and Implementation draft. Note that e.g. "Final" has more implementation details in the API draft than in the implementation draft.
Change:
recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource. <del> 4.2.3. </del> <ins> 4.2.4. </ins> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the

Discussion:
Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL