jiebi/CodeConvo huggingface dataset:
Change:
successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. <ins> 7.5. There may be cases where a server cannot perform automated validation of an identifier, for example if validation requires some manual steps.  In such cases, the server may provide an "out of band" (OOB) challenge to request that the client perform some action outside of ACME in order to validate possession of the identifier. The OOB challenge requests that the client have a human user visit a web page to receive instructions on how to validate possession of the identifier, by providing a URL for that web page. The string "oob-01" The URL to be visited.  The scheme of this URL MUST be "http" or "https" A client responds to this challenge by presenting the indicated URL for a human user to navigate to.  If the user choses to complete this challege (by vising the website and completing its instructions), the client indicates this by sending a simple acknowledgement response to the server. The string "oob-01" On receiving a response, the server MUST verify that the value of the "type" field is as required.  Otherwise, the steps the server takes to validate identifier possession are determined by the server's local policy. </ins> 8. [[ Editor's Note: Should we create a registry for tokens that go into

Discussion:
We need a challenge type to cover types of validation that can't be done automatically, in band to ACME. For example, a CA doing OV or EV validation might need the applicant to upload some documents through a web form. We should add a generic "out-of-band" challenge type that has a URL for a web site where the applicant gan go for instructions. I think the challenge object would look something like: There would be no response object; you just click the link, and when you complete the instructions there, the CA reflects this in the "status" field of the challenge object.
A few months back I wrote up a for this idea -- the hope is that ACME could evolve to become the language that all cert issuers talk to support a standard for cert management and exchange.
At IETF 95, agreed that this seemed reasonable to pursue, but needs to have a PR that describes what the URI characteristics are.
Change:
responses and so might be ignorant of the use of oblivious HTTP to reach it. <ins> This draft includes pseudocode that uses the functions and conventions defined in HPKE. This draft uses the variable-length integer encoding from Section 16 of QUIC.  Encoding and decoding variable-length integers to a sequence of bytes are described using the functions "vencode()" and "vdecode()".  The function "len()" takes the length of a sequence of bytes. Formats are described using notation from Section 1.3 of QUIC. </ins> 3. A client learns the following:

Discussion:
This just expands the text and tries to be explicit about everything. The one change I've included here is a change from 32 to Nsk for the exported secret. I think that's in line with the HPKE intent. Constants make me nervous.
I'm going to merge, and then apply my suggestions and the nonce change in a followup PR.
In our discussion of , NAME and I explored the ways in which nonce reuse might occur. The problem arises if the client reuses . This leads to nonce reuse on the request for sure. However, if the request is the same, the problem shifts to the response. Unless the response is also identical, we get nonce reuse on the response instead. We then discussed options for safeguarding against this. As the client is expected to include randomness in its derivation of its key, it seems like the failing is not something that adding extra steps at the client will address. So I don't think that adding anything to the request really helps. Separately, HPKE code is supposed to be stateful. Reuse of a context should result in the sequence number increasing, leading to a nonce that the server cannot reconstruct (unless it also counts and does trial decryption, but that's two bad actors). That should ensure that the client doesn't use the same nonce twice. You really have to have bad randomness at the client to get into a deliberate nonce reuse scenario if you trust that the HPKE implementation is properly stateful. However, a response that is generated in response to a replayed request is something I am concerned about. We know that HTTP clients routinely do, even if the request is marked POST. So some protection here is warranted. For this, I'm going to suggest that we change from salting based on the request to salting based on . Hashing the entire message is likely to be very expensive, both in terms of cycles, but also in terms of state. The public key should be enough to ensure the binding in the case where a client doesn't reuse the context, and the new randomness should help in case of reuse. I think that it's OK to use 128 bits of extra randomness here, but we don't have a handy constant to hang that on. Nn is 96, Nk could be 128 or 256 depending on the AEAD.

What we really want is the block size, but that isn't a property that is exposed anywhere.
I think this is the right design on balance. If we were more conservative, we could include the entire client request (including ), but that doesn't really hedge against the misuse scenario. I'll propose text in .
Fixed in .
Change:
of failure, the input share is marked as invalid with a corresponding ReportShareError error. <del> The validation checks are as follows. </del> <ins> Before beginning the preparation step, Aggregators are required to perform the following generic checks. </ins> Check if the report has never been aggregated but is contained by a batch that has been collected.  If this check fails, the input

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
passed by a misconfigured server; or a high RateLimit-Reset field value could inhibit clients to <del> contact the server. Clients MUST validate the received values to mitigate those risks. </del> <ins> contact the server (e.g. similarly to receiving "Retry-after: 1000000"). To mitigate this risk, clients can set thresholds that they consider reasonable in terms of quota units, time window, concurrent requests or throughput, and define a consistent behavior when the RateLimit exceed those thresholds.  For example this means capping the maximum number of request per second, or implementing retries when the RateLimit-Reset exceeds ten minutes. The considerations above are not limited to RateLimit fields, but apply to all fields affecting how clients behave in subsequent requests (e.g.  Retry-After). </ins> 7.

Discussion:
no normative language in sec- -
This doesn't seem practical; how would validation help? What are they looking for?
For example, implementations are expected to validate received values like Or The same goes for other fields, e.g. A similar practice, in a different context though, is mentioned in URL Hints are welcome!
Considering the objective of the RateLimit headers is to allow a client to avoid being throttled, the consequence of a client ignoring the RateLimit-* headers is just a client getting throttled. If we believe that a client may need to protect itself against malicious values injected into these headers, then I it should be sufficient to give clients the permission to ignore the headers if they believe the values are not reasonable. Suggest wording like: However, considering that processing these headers is optional for a client anyway, I'm not sure this comment is absolutely necessary.
Part of the problem here is that "valid" is being used in different senses: to indicate that it's a valid Structured Field to indicate that it's semantically valid (e.g., "too big") For the latter, since it's so fuzzy (at least to date), I'd suggest using something like "reasonable" instead.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
Change:
The AS responds with a handle appropriate to represent the resources list that the RS presented. <del> The RS MAY make this handle available as part of a rs-request- without-token or as documentation to developers. </del> <ins> The RS MAY make this handle available as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to developers. </ins> [[ See issue #117 [2] ]]

Discussion:
See also related PR at ietf-wg-gnap/gnap-core-protocol
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit ec0063ea1a01f824c05137ecaaf8c7760dfee083 https://deploy-preview-26--gnap-resource-servers-editors-URL
Following the review I checked this PR too, seems fine
Change:
6. <del> 6.1. </del> <ins> It's been observed that a significant number of middleboxes intercept and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections that adopt certificate compression. However this is not a problem when using TLS version 1.3 [draft-ietf- tls-tls13] and higher, due to the fact that the Certificate (and thus the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7. 7.1. </ins> Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246). <del> 6.2. </del> <ins> 7.2. </ins> Create an entry, compressed_certificate(TBD), in the existing registry for HandshakeType (defined in RFC5246). <del> 6.3. </del> <ins> 7.3. </ins> This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled

Discussion:
I feel like we should provide a somewhat more specific guidance. "Server implementations MAY choose to negotiate certificate compression only in cases when the TLS version is 1.3 or newer"? (SHOULD is also fine, we should probably pick whatever level draft22 compat hacks use)
AFAICT draft22 doesn't use any specific RFC2119 words for the compat mode (it just says "can use" a bunch of times). Also, I think this is somewhat different in that there's no real change between TLSv1.2 and TLSv1.3 for compression (differently from the TLSv1.3 compat mode where the protocol actually slightly changes). So, knowing the risk, it should just be up to the server and the client to decide whether to use compression or not with TLS < 1.3 IMO.
Good point.
Change:
Operates and interacts with the RC. <del> The GNAP protocol design does not assume any one deployment architecture, but instead attempts to define roles that can be fulfilled in a number of different ways for different use cases.  As long as a given role fulfills all of its obligations and behaviors as defined by the protocol, GNAP does not make additional requirements on its structure or setup. </del> <ins> The design of GNAP does not assume any one deployment architecture, but instead attempts to define roles that can be fulfilled in a number of different ways for different use cases.  As long as a given role fulfills all of its obligations and behaviors as defined by the protocol, GNAP does not make additional requirements on its structure or setup. </ins> Multiple roles can be fulfilled by the same party, and a given party can switch roles in different instances of the protocol.  For

Discussion:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.
Change:
identifiers.  For example, all of the identifier validation challenges described in identifier-validation-challenges below address validation of domain names.  The use of ACME for other <del> protocols will require further specification, in order to describe </del> <ins> identifiers will require further specification, in order to describe </ins> how these identifiers are encoded in the protocol, and what types of validation challenges the server might require.

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 !
Change:
is also invoked). Calling "Clone" on an SCTP association creates a new Connection <del> object and assigns it a new stream number in accordance with the stream number assignment procedure described above.  If there are not enough streams available, ADD_STREAM.SCTP must be called. </del> <ins> object and assigns it a new stream id in accordance with the stream id assignment procedure described above.  If there are not enough streams available, ADD_STREAM.SCTP must be called. </ins> When this value is changed, or a Message with Message Property "Priority" is sent, and there are multiple Connection objects

Discussion:
This is a manual re-application of all the changes to -impl in PR . (Other methods didn't easily work because the master has changed quite a bit during discussion of PR ; at least I found no easy way).
Sec 10.6 of taps-impl is pretty confusing: .. there's yet more. Maybe I should read NEAT-flow-mapping, or remind myself about the details of SCTP, but I think the third sentence (To map Connection Objects...) is not well-constructed. There are three conditions here: both SCTPs must: support 8260,support stream reconfiguration, ANDknow what's going on. But what do these conditions enable? Is it mapping connections to streams at all? Is it mapping them without HOL blocking (i.e., if not met, I still can map but there is HOL blocking)? Something else?
Guilty as charged! I wrote this and I can fix it. Meanwhile, I'll explain: 8260 => to reduce HOL blocking delay. stream reconfiguration => to save memory and be able to re-use stream numbers, and to realize the role of a FIN (stream reset = FIN) know what's going on => yes, but this is an application requirement ... the applications on both sides must be able to handle this. E.g., a server written over a TAPS system could just listen on all protocols, including streams, and get whatever kind of Connection (including, possibly, one that's really only a stream) - and then answer on it (I actually tested exactly this with NEATPy). This server can handle this easily. Another server could be a native TCP server, certainly not expecting SCTP, let alone Connections riding on streams - this server could not handle this. The client application, when connecting, must know what it's doing. I can make a PR to explain these matters in the text.
Change:
deadlocked if the decoder withholds flow control credit until the instruction is completely received. <del> To avoid these deadlocks, an encoder SHOULD avoid writing an instruction unless sufficient stream and connection flow control credit is available for the entire instruction. </del> <ins> To avoid these deadlocks, an encoder SHOULD NOT write an instruction unless sufficient stream and connection flow control credit is available for the entire instruction. </ins> 2.1.4.

Discussion:
NAME said
I think we can change to SHOULD NOT. I'd rather not be so prescriptive here, since a QPACK implementation might well cut this corner and ignore flow control constraints and rely on higher levels of the stack to ensure the necessary flow control is available? I guess I could be convinced otherwise.
NAME
NAME said
Even though newlines are not really allowed (unescaped) in field values, we can add a note to this effect.
NAME said
Yes, that's why they're not there.
Propose to close with no action then? Or is there a way to reformat the table to include the longer names?
I see a couple options in addition to "close with no change", namely to add a note below the table that the names are abbreviated, or to write out the IANA directives in prose without a table at all. I don't have a particular preference among those three options, though.
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
NAME said
I agree it's not worth mitigating technically. I question whether it's worth documenting, personally, but it does no harm.
Maybe just a sentence that this mitigation has limits when traversing multiple intermediaries?
That seems like it would strike a reasonable balance.
NAME said
This table appears before the general discussion of indexing. One thought is to add something along the top of the table, like this: ?
Your proposal does improve the clarity of the figure, but I am hoping for more. While it is true that the dedicated sections that discuss indexing appear later in the document, the introductory text alongside the figure uses language such as "smallest absolute index", increases the draining index", and "with an absolute index lower than the draining index" that imply a numerical ordering and directionality of the indices. Interpreting the figure would be easier with the direction of that ordering stated explicitly, as might be done via "Newer Entries (larger index)"/etc..
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
Change:
or to assign the traffic to a lower-effort service.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling SHOULD assign the DSCP Less <del> than Best Effort LE-PHB PHB. </del> <ins> than Best Effort RFC8622 PHB. </ins> The application is interactive, and prefers loss to latency. Response time should be optimized at the expense of bandwidth

Discussion:
: added a statement about data arriving before Receive is issued; : removed the confusing sentence; : carried out replacements suggested by NAME
This issue comes from other discussion at the interim of what it means to map to DSCP classes, and proposes to fix two topics. Replace reference OLD: DSCP Less than Best Effort [LE-PHB] PHB NEW: DSCP Less than Best Effort [RFC8622] PHB — Low Latency/Interactive: The current advice is wrong. An endpoint never should be assigning EF without understanding the implication of CAC and policing. OLD: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; NEW: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) [RFC2597] PHB. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding [RFC3246] or [RFC5865] PHBs. —
The new text resolve this issue.
I'm not sure I understand this sentence (in sec 8. - Receiving Data): "As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's transport parameters." Especially, what's meant by "type of Message"?
Change:
Many different attacks have been reported as part of revelations associated with pervasive surveillance.  Some of the reported attacks <del> involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved.  However, the danger of resourceful attackers for these systems is still a concern. </del> <ins> involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved.  However, the danger of resourceful attackers for these systems is still a concern.  Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. </ins> This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC9048.  The extension,

Discussion:
Not sure the attacks actually attacked the smart cards. Changed to "smart card supply chain" in the abstract and intro. This is very much related to zero trust principles. added a sentence about this. Any modern standard track EAP method should provide mandatory client identity protection. Copied the text from EAP-TLS 1.3 Motivation for the chosen curves is missing. Added link to the definition of SUCI encryption in appendix C.3.4. of TS 33.501 Added more text in security consideration on the attacks an attacker can do. Added more text in security consideration on frequent use of ECDHE.
Great! There's one typo but I'll fix it.
Change:
5.5. Issuers are configured with Private and Public Key pairs, each <del> denoted "skI" and "pkI", respectively, used to produce tokens.  A RECOMMENDED method for generating key pairs is as follows: </del> <ins> denoted "skI" and "pkI", respectively, used to produce tokens.  These keys MUST NOT be reused in other protocols.  A RECOMMENDED method for generating key pairs is as follows: </ins> The key identifier for a public key "pkI", denoted "token_key_id", is computed as follows:

Discussion:
diverges from . In the earlier section: In the latter, this approximates to: ... with no 0x0002.
I would be fine with adding a token type separator to the type2 variant. It's a simple enough change to make and deploy right now. NAME NAME thoughts?
NAME is there a reason the type 1 key ID needs 0x0001 concatenated to it?
We did this for separation between privacy pass and other potential uses of the same key. I don't remember exactly why we didn't do this for type2.
Had a call, proposing to make things consistent by removing the for Type 1, since it doesn't seem to add any benefit, since the token_input is already binding the protocol to the type and challenge. Also recommending adding more text (in security considerations) to make it very clear that keys ought to not be reused across protocols.