jiebi/CodeConvo huggingface dataset:
Change:
be a significant problem, because it allows a fleet of devices to be held hostage for ransom. <del> In the case, the Relying Party is the watchdog timer in the TPM/ secure enclave itself, as described in TCGarch section 43.3.  The Attestation Results are returned to the device, and provided to the enclave. If the watchdog does not receive regular, and fresh, Attestation Results as to the systems' health, then it forces a reboot. </del> <ins> A solution to this problem is a watchdog timer implemented in a protected environment such as a Trusted Platform Module (TPM), as described in TCGarch section 43.3.  If the watchdog does not receive regular, and fresh, Attestation Results as to the system's health, then it forces a reboot. </ins> The device that should be protected from being held hostage for a long period of time

Discussion:
Also improve wording of watchdog use case's discussion of TPMs. Signed-off-by: Dave Thaler
This section, as put, is kind of a big leap, no? I think the important part of this next level, is the introduction of a hardware root of trust like a TPM to eliminate the need to trust the device’s operating system software in reporting attestation results.
NAME How about "For strongest security,...." to avoid confusion with high level OS.
This also already fixed by existing text .
If a TPM is the Attesting environment, then in the case where this system had a TPM, this statement would not be true, no? In other words, shouldn’t this example be restricted to attestation without a TPM? (I think you can say something like “hardware root of trust for verification” or something if we should avoid naming technologies) In contrast, I think in a TPM system, the firmware initializes the Attesting Environment, the TPM is the attesting environment, and the same attesting environment is used by all layers.
For context, Guy's comment was on the first sentence in this paragraph: My understanding is that a TPM requires another entity to feed it measurements which the TPM measures, the TPM doesn't actively collect claims itself. Thus to me, the TPM is not the Attesting Environment. The Attesting Environment is the combination of the TPM + whatever is feeding it the measurements. Viewed that way, I believe the text is true as written.
Yes. We need text that captures that prominently and then also in that text start with "the composite of TPM &amp; root of trust for measurement" forms an Attesting Environment instead of "he TPM is not the Attesting Environment". Starting with the latter seems to produce reflexive and unnecessary knee-jerk reactions that we can also easily resolve, finally. Does that sound like a feasible approach?
Yes I like that.
section: ## Two Types of Environments of an Attester now includes text: ~ What else do you want to say? 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?
Change:
All QUIC packets except Version Negotiation packets use authenticated encryption with additional data (AEAD) RFC5116 to provide <del> confidentiality and integrity protection.  Retry packets use an AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process. </del> <ins> confidentiality and integrity protection.  Retry packets use AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process. </ins> Initial packets are protected using keys that are statically derived. This packet protection is not effective confidentiality protection.

Discussion:
Is "AEAD" a thing, or a descriptor? I read the original as "an AEAD [algorithm]", but this change seems to consider AEAD as a technique which can be applied.
I modeled this on the previous sentence that says (italics added): Note the absence of "an" in front of the italicized text. The "AEAD" in the second sentence is simply another way to write "authenticated encryption with additional data."
Change:
Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of <del> communicating beyond the constraints of the captive network. </del> <ins> communicating beyond the constraints of the Captive Portal. </ins> User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity.

Discussion:
A reviewer found a problem with some phrasing, and also noticed that we missed a few captive networks. Clean them up.
Change:
relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy. <del> 9. </del> <ins> 8. </ins> The following diagram illustrates a relationship to which attestation is desired to be added:

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
not used. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </del> <ins> MUST contain an "a=rtcp-mux" attribute.  If an m= section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:

Discussion:
The local description can never be wrong, because it is constructed by the browser. I also explicitly added text to make clear that the mux state for any m= line cannot change.
LGTM
Section 5.8 describes the behavior of an implementation processing its own unmodified SDP. It contains significant error language that should have been removed when SDP munging was removed. In particular, please remove all of the following: • "If an error is returned, the session MUST be restored to the state it was in before performing these steps." • "If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error." • "If any indicated RTP header extension is not supported, this MUST result in an error." • "If any indicated media format is not supported, this MUST result in an error." • "If any referenced primary payload types are not present, this MUST result in an error." The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only.
I think Adam is right about this, but I wonder if this actually belongs elsewhere, so further study needed.
This is already duplicated. This seems to be a prohibition that is stricter than RFC 5761, and if we remove it here we have removed it generally, unless I have missed somewhere else we say it. This is not appropriate for remote descriptions. We say this in 5.9. >The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only. Yeah, I think Adam is right about this and it's probably the result of some section refactor
Made some progress on it. Editor discussion on the mux piece. Once an m= line has mux or non-mux negotiated, that's immutable.
LG with nits
Change:
media metadata The IV is 128 bits long and calculated from the CTR field of the <del> Frame header: </del> <ins> Frame header.  First the var int CTR is decoded into 16 bytes long field, where CTR fills the the 8 most significant bytes and low 8 bytes are always filled with zeros: </ins> 4.3.2.

Discussion:
Add more information for how the CTR is used to derive the final IV
The current IV equation is IVCounter XOR SaltKey. This will lead to IV reuse across multiple blocks in AES-CTR for example Frame 0 AES(0) XOR Block0, AES(1) XOR Block1, AES(2) XOR Block2,... Frame 1 AES (1) XOR Block0, AES(2) XOR Block1, AES(3) XOR Block2,.. Frame 2 AES(2) XOR Block0, AES(3) XOR Block1, AES(4) XOR Block2,... The equation should be changed to shift the frame counter to high significant 8 bytes and the other 8 bytes will be zeros then do the XOR FrameCounter8 = DecodeVarIntIntoInt64(counter) FrameCounter16 = FrameCounter << 8 IV = FrameCounter16 XOR SaltKey
lgtm
Change:
2.1. For any host candidate gathered by an ICE agent as part of RFC8445 <del> section 5.1.1, obfuscation of the candidate is done as follows: </del> <ins> section 5.1.1, the candidate is processed as follows: </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. <del> If there is a registered hostname, replace the IP address of the ICE host candidate with the hostname.  Expose the candidate and abort these steps. </del> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

Discussion:
Fingerprinting question will be tracked in a new issue.
Merging this one with Jeroen's approval.
LGTM
Change:
6. <del> Prior to receiving an ACK-FREQUENCY frame, endpoints send </del> <ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send </ins> acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. <del> On receiving an ACK-FREQUENCY frame and updating its recorded </del> <ins> On receiving an ACK_FREQUENCY frame and updating its recorded </ins> "max_ack_delay" and "Packet Tolerance" values (multiple-frames), the endpoint MUST send an acknowledgement when one of the following conditions are met:

Discussion:
Also rename ACK-FREQUENCY to ACK_FREQUENCY to
Use instead of following naming convention in the transport draft.
Change:
HTTP Signing signature header <del> OAuth PoP key proof authentication header </del> Additional proofing methods are defined by IANA. All key binding methods used by this specification MUST cover all

Discussion:
remove OAuth DPoP binding. Described why on IETF mailing list: OAuth PoP: expired draft, due to be replaced with new draft based on HTTP Message Signatures. Also closing and
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: a47cdeabae554f3636d63a0ce8e0f8b52ff53693 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Removed autoindent in my editor to fix the issue
OAuth Proof of Possession (PoP): Editor's note: This is a stale draft from the OAuth working group, but it does at least provide some basic functionality for protecting HTTP messages with a signature. This work is likely to be subsumed by the general-purpose HTTP message signature mechanism in Section 8.5.
OAuth Proof of Possession (PoP): Editor's note: This is in contradiction to the referenced spec which makes this field mandatory.
Change:
Parameters.  Action and Event parameters whose names are suffixed with a question mark are optional. <del> Actions associated with no Object are Actions on the API; they are equivalent to Actions on a per-application global context. </del> <ins> Objects that are passed as parameters to Actions use call-by-value behavior.  Actions associated with no Object are Actions on the API; they are equivalent to Actions on a per-application global context. </ins> Events are sent to the application or application-supplied code (e.g. framers, see framing) for processing; the details of event processing

Discussion:
There are several places where the document says "Changes to a after func() has been called do not have any connection on existing s". This feels like an opportunity for more clarity about what a really is. The document uses the word Object, and maybe there's an assumption that there's a shared understanding of what the properties of an Object are. Being explicit with something like "An Object is a collection of properties that implementations of the API read and use..." to avoid the "here's a chunk of memory that can get passed into the API that it can operate on, and expect the caller to see the effects of the operation" interpretation. I think what the current text is trying to say is that the user of the API should assume the implementation of the API made its own private copy of the Object at the point of the given func() call and that it will not see any changes to the copy the user has at any later point. But then there's some text that looks like "Once a has been used with a func(), it is invalid to modify any of its properties." So...
Change:
available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section. <ins> 4.1. Servers are not required to return "RateLimit" fields in every response, and clients need to take this into account.  For example, an implementer concerned with performance might provide "RateLimit" fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </ins> 5. This section documents the considerations advised in Section 16.3.3

Discussion:
servers are not forced to always return ratelimit fields clients must not assume the presence of ratelimit fields performance hints for providers
Waiting for NAME then :)
NAME PTAL :)
Looks great to me. The intent is nice and clear.
The spec to define header inter-dependencies and returning policies [x] Limit -> Reset [x] Limit, Remaining, Reset Do I have to always return all headers? No Do I have to expose all headers or I can only expose a subset? Limit,Reset are REQUIRED, Remaining is OPTIONAL Do we need to add some considerations on client implementation? Already present.
clarifies that clients MUST NOT assume a server always returns fields
Comment by Erik. In https://ietf-wg-URL You state ‘A server MAY use one or more "RateLimit" response fields defined in this document to communicate its quota policies.’ but it does not clearly define how they would be used in isolation or how a client should respond to a limited set of headers (other than discussed earlier above) My feeling is RateLimit-Limit can be optional and RateLimit-Remaining and RateLimit-Reset can be used as a pair. RateLimit-Reset would only have value in isolation if sent with a 429 response code, on other responses it would be meaningless.
It could also make sense to return Reset with other status codes such as and , so I think we don't really want to mandate a specific relation other than, at most, saying that unsuccessful requests (for a broad definition of those, possibly including and at a minimum) with this field are expected to be unsuccessful until that time elapses.
After a couple of years of adoption, my experience is the following: implementations use all 3 fields. Though theoretically one could just return and , I never found an implementation doing this :heavycheckmark: implementations don't know Remaining, and just return Limit and Reset with a fixed window (eg. 1 second). We can then recommend the following: Limit, Reset: MUST Remaining: SHOULD Since https://ietf-wg-URL I now think that we shouldn't mess with status codes. NAME if this sounds reasonable to you, I can provide a PR
Yes, it sounds good, thank you!
Looks good!
Change:
MUST NOT be used. A response MAY consist of multiple messages when and only when one or <del> more informational responses (1xx; see RFC7231, Section 6.2) precede a final response to the same request.  Non-final responses do not contain a payload body or trailers. </del> <ins> more informational responses (1xx; see Section 6.2 of RFC7231) precede a final response to the same request.  Non-final responses do not contain a payload body or trailers. </ins> If an endpoint receives an invalid sequence of frames on either a request or a push stream, it MUST respond with a connection error of

Discussion:
Martin flagged this on some imported text in , but others have crept in other places, mostly also as text imported from RFC7540. For future reference, (({{])), (Section d+(.d+)*) => 1
Change:
application_data, and alert respectively) but are protected under different keys.  After all the 0-RTT application data messages (if any) have been sent, a "end_of_early_data" alert of type "warning" is <del> sent to indicate the end of the flight. </del> <ins> sent to indicate the end of the flight.  Clients which do 0-RTT MUST always send "end_of_early_data" even if the ServerConfiguration indicates that no application data is allowed (EarlyDataType of "client_authentication"), though in that case it MUST NOT send any non-empty data records (i.e., those which consist of anything other than padding). </ins> A server which receives an "early_data" extension can behave in one of two ways:

Discussion:
This cleans up some of the text around EarlyDataIndication that was introduced previously.
The early data indication parameters are defined as clientauthentication(1), earlydata(2), and clientauthenticationanddata(3). A few paragraph after that, some text refers to them by what was probably an old name: If TLS client authentication is being used, then either "earlyhandshake" or "earlyhandshakeand_data" MUST be indicated in order to send the client authentication data on the first flight. Easy fix...
See URL
This should now be fixed.
Change:
including but not limited to the calendar system it needs to be represented in. <ins> 1.1. </ins> This document defines an extension syntax for timestamps as specified in RFC3339 that has the following properties:

Discussion:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.
Change:
The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates <del> have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del> <ins> are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer.

Discussion:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm
Change:
defined in I-D.ietf-ice-trickle, Section 5.1. I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into <del> different categories.  To avoid unnecessary duplication when bundling I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1, specifies that attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </del> <ins> different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, as specified in I-D.ietf-mmusic-sdp- bundle-negotiation, Section 8.1.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:

Discussion:
I like the text in your comment and changed to that.
Worth taking an editorial pass over this if time permits
I prob have time to run this one down.
Change:
2. <del> The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is intended to verify that the server actually speaks for the domain(s). Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain Validation" (DV) certificates are by far the most common type.  For DV validation, the CA merely verifies that the requester has effective control of the web server and/or DNS server for the domain, but does not explicitly attempt to verify their real-world identity. (This is as opposed to "Organization Validation" (OV) and "Extended Validation" (EV) certificates, where the process is intended to also verify the real-world identity of the requester.) </del> <ins> The guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In this case, the user's web server is intended to speak for one or more domains, and the process of certificate issuance is intended to verify that this server actually speaks for the domain(s). </ins> DV certificate validation commonly checks claims about properties related to control of a domain name - properties that can be observed

Discussion:
Several comprehensibility improvements to the first three sections of the draft RFC. For clarity about the contents of this pull request, please consider using the option (git CLI) or the "rich diff" option (GitHub web interface) to evaluate it, in preference to a traditional line-based diff.
NAME - I think these changes are valuable. Thank you! I don't personally have any qualms/feedback having read through the diff but it would help get more eyes on this if you emailed the ACME mailing list with a brief mention of your PR (even though it's strictly editorial I think more folks monitor the list than the Github repo).
LGTM. Thanks NAME !