jiebi/CodeConvo huggingface dataset:
Change:
(i.e. 2^62-4 in case of QUIC version 1).  This GOAWAY frame signals to the client that shutdown is imminent and that initiating further requests is prohibited.  After allowing time for any in-flight <del> requests (at least one round-trip time), the server would send another GOAWAY frame with an updated last Stream ID.  This ensures that a connection can be cleanly shut down without causing requests to fail. </del> <ins> requests to reach the server, the server can send another GOAWAY frame indicating which requests it will accept before the end of the connection.  This ensures that a connection can be cleanly shut down without causing requests to fail. </ins> Once all accepted requests have been processed, the server can permit the connection to become idle, or MAY initiate an immediate closure

Discussion:
using mostly the text proposed in that issue.
On NAME proposes a change to GOAWAY that reduces the exposure of the QUIC API to HTTP/3. The paragraph in question also suggests behaviour that relies on exposure of QUIC transport information: . This seems to be the only occurence of round-trip time in the HTTP/3 document. I think we can editorialize ourselves out of this. For some HTTP/3 implementations, the RTT could be readily accessible, for others maybe not.
The other issue of the last two sentences (quoted below) is that they do not suggest how an endpoint should choose last Stream ID of the second GOAWAY frame.
Regarding how we should change, maybe something like below would be sufficient. My observation is that we can drop "at least one round-trip time" because the text that directly precede that implies that already. "After allowing time for any in-flight requests to reach the server, the server MAY send another GOAWAY frame that carries the greatest request stream ID it has seen. This ensures that a connection can be cleanly shut down without losing requests."
The text implies a little bit of interaction with the QUIC Stream ID space. Because we had to change GOAWAY to signal the first unprocessed Stream ID, the HTTP layer needs to be able to get "the next" stream ID from QUIC in a given space. But as to the general issue, I don't object to removing the specific dependency; anyone reading should be able to conclude that you need to allow an RTT for the requests to arrive, and if they have access to that value, they'll use it.
Seems alright.Thanks!
Change:
2.3. <ins> [ TBD move information model in here ] </ins> A describes a relationship between two resources on the Web.  As in

Discussion:
The requirement was probably a left-over from when CRIs where specified in here; the current document has no use for the properties obtainable from this. Closes: URL
The current text says: I think this is a remnant from when CoRAL and CRI were a single document; I don't see any reason to prescribe this for CoRAL. Any objections to removing that?
Change:
specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. <ins> If present, a single "a=rtcp-mux-only" attribute MUST be parsed as specified in I-D.ietf-mmusic-mux-exclusive, Section 3, and its presence or absence flagged and stored. </ins> If present, a single "a=rtcp-rsize" attribute MUST be parsed as specified in RFC5506, Section 5, and its presence or absence flagged and stored.

Discussion:
Not ready yet.
LGTM with editorial comment as above.
Please apply same presence/absence treatment for all
http://rtcweb-URL [TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level.]
(session-level, specifically)
Change:
msg-lifetime <del> Integer </del> <ins> Numeric </ins> infinite

Discussion:
Example code updates: this is to try to avoid people stumbling over, e.g., "send" being part of the "main code". I believe it's a little cleaner with these added comments.Lifetime Message property: mentioned -1 as a special value for infinite, else it's a bit odd to only use "infinite" for an integervery minor text fix about corruption protection length Message property
Okay, so I think I addressed NAME comments here, and agreed with NAME that we could adjust things further later on if needed - so now I'll just merge this one, seems safe to do to me.
These two message properties are interconnected and therefore have a dependency. I would rather prefer to only have one property. Lifetime already has one "special" value (infinity) to indicate reliable transmission. We could also declare 0 as special to indicate unreliable transmission (only transmit once and never retransmit). Also should we rather use -1 for reliable? And also do this for other properties that currently have meaning for infinite? Or would it be more correct to say max instead of infinite? And more more question on lifetime: Do we need an event that indicates to the application that transmission was aborted due to lifetime expiry?
No. Here's a quote from the description of lifetime: " Setting a Message's Lifetime to infinite indicates that the application does not wish to apply a time constraint on the transmission of the Message, but it does not express a need for reliable delivery; reliability is adjustable per Message via the "Reliable Data Transfer (Message)" property (see Section 7.4.7). " Consider an unreliable, congestion controlled transport (e.g. QUIC with datagrams). Specifying a "lifetime" means that, once the lifetime has expired, the Message can be deleted from the send buffer. Setting "lifetime" to infinite means that the Message will never just be deleted from the send buffer. This does not at all guarantee that the Message will be retransmitted in case it was lost. The mistake is the mix of "integer" and "infinite". The latter is okay for type "numeric". I have already fixed this in PR (which is still open). That's the Expired Event, see section 7.3.2.
Can we close this issue?
Interim: Agreed with NAME closing.
Change:
The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per <del> registration.  The scheme://authority value of the registration is taken from the requesting server's URI. </del> <ins> registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
that always waits for the Sent Event before calling the next Send Action. <del> 8.2.3.2. </del> <ins> 8.2.2.2. </ins> The Expired Event occurs when a previous Send Action expired before completion; i.e. when the Message was not sent before its Lifetime

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
a mode in which clients do not validate the name of the resolver presented in the certificate.  Opportunistic Privacy similarly applies to DoQ RFC9250.  A client MAY use information from the SVCB <del> record for "dns://resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses.  This approach can be used for any encrypted DNS protocol that uses TLS. </del> <ins> record for "resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver. Clients SHOULD use this mode only for resolvers using private or local IP addresses.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.

Discussion:
There is no need to use a DNS URI for this. You are only using the name. And you don't cite RFC 4501. It is also incorrect, because you are treating "URL" as the authority, rather than the qname. What you really want is "URL;type=64" or something like that. But the words you have are adequately clear.
Change:
attacker and ignore it without sending an error message or discontinuing the session. <del> 8.7. </del> <ins> 8.8. </ins> The availability of a secure random number generator is essential for the security of EDHOC.  If no true random number generator is

Discussion:
IAB has started a program to look into updates of the Internet Threat Model. Looks like the outcome might be a guidance document. One new threat is centralised data collection where the other endpoint might not be acting in the interest of the users. URL URL There is not reason to change the protocol, but I think it would be good with some privacy considerations. Using the same credentail with several other endpoints enables tracking. I will make a PR soon with a reference to draft-arkko-arch-internet-threat-model-guidance
This has been merged for a while without any comments. Was discussed at the interim. Closing.
Looks good, I made some editorials.
Change:
the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. <del> A direction attribute for the associated RtpTransceiver described by sec.answer-dirattr. </del> <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and

Discussion:
Can you separate this from the ICE changes that are also in this PR?
Oops, yeah
NAME PTAL
LGTM
See URL
Change:
have an owner registrar deployed.  The cloud registrar issues a voucher, and the pledge completes trust bootstrap using the cloud registrar.  The voucher issued by the cloud includes domain <del> information for the owner's EST service the pledge should use for certificate enrollment. </del> <ins> information for the owner's Enrollment over Secure Transport (EST) RFC7030 service the pledge should use for certificate enrollment. </ins> In one use case, an organization has an EST service deployed, but does not have yet a BRSKI capable Registrar service deployed.  The pledge is deployed in the organization's domain, but does not <del> discover a local domain, or owner, registrar.  The pledge uses the cloud registrar to bootstrap, and the cloud registrar provides a voucher that includes instructions on finding the organization's EST service. </del> <ins> discover a local domain registrar or owner registrar.  The pledge uses the cloud registrar to bootstrap, and the cloud registrar provides a voucher that includes instructions on finding the organization's EST service. </ins> 2.

Discussion:
[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?
Change:
7.3.3. <del> Servers SHOULD NOT respond to GET requests for account resources as </del> <ins> Servers MUST NOT respond to GET requests for account resources as </ins> these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the "contact" or "orders" fields), then it SHOULD do so by sending a POST

Discussion:
Section "Request Authentication" already forbade it.
In general, we have not been making MUST-level requirements for servers in this document because CAs are subject to a lot of external constraints already. Under that theory, I would say we should just close this. NAME NAME wdyt?
If you don't want this change, can you change "Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification." instead to resolve the inconsistency?
NAME I agree with NAME - this isn't a new MUST-level requirement, it's already said elsewhere that the server MUST NOT respond to sensitive resources and the account object has contact information you wouldn't want returned to an unauthenticated GET request. It seems fine to emphasize this in the account information section.
I'm going to merge this. NAME gives an OOB +1. Thanks NAME !
Change:
the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. <ins> The signatures used throughout this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined as the concatenation of "r" and "s" as specified in RFC8032. </ins> Note that each new credential that has not already been validated by the application MUST be validated against the Authentication Service.

Discussion:
The spec doesn't say anything about the signature encoding yet. This PR adds a paragraph clarifying that signature encoding is done like in TLS.
Change:
the task ID obtained from the task parameters, encoded in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize <del> the task ID, then it responds with HTTP status code 400 Bad Request and an error of type "unrecognizedTask". </del> <ins> the task ID, then it MUST abort with error "unrecognizedTask". </ins> An aggregator is free to use different HPKE configurations for each task with which it is configured.  If the task ID is missing from a

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged
Change:
between the pledge and the cloud registar are all out of scope of this document. <del> 2.3. </del> <ins> 2.2. </ins> BRSKI section 5.9.2 specifies that the pledge MUST send an EST RFC7030 CSR Attributes request to the registrar.  The registrar MAY

Discussion:
I find this section too telegraphic. Needs a bit more grammar...
Maybe we just delete this section completely NAME ?
I think we should eliminate the heading, but expand the content to better match the diagram.
I'm not convinced. In the rest of the doc, we never mention OEM or Network integrator. And Network operator is only mentioned again in secetion "Issues with Security of HTTP Redirect" I lean to delete completely, unless you have some explicit ideas and concepts you need to get across. FIne if you do - maybe include that in your abstract rewrite PR?
This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar).
No, this is a runon sentence. It is worth. Let me work on something for Friday.
Change:
RESET_STREAM frame instead of retransmitting the data. An endpoint SHOULD copy the error code from the STOP_SENDING frame to <del> the RESET_STREAM frame it sends, but MAY use any application error </del> <ins> the RESET_STREAM frame it sends, but can use any application error </ins> code.  An endpoint that sends a STOP_SENDING frame MAY ignore the error code in any RESET_STREAM frames subsequently received for that stream.

Discussion:
Barry Leiba said:
The other reference was: — Section 3.5 — An endpoint SHOULD copy the error code from the STOPSENDING frame to the RESETSTREAM frame it sends, but MAY use any application error code. I'm OK with changing to "can".
I don't think we need to do this; I've suggested changes on the PR.
Ok, let's merge this one, and I'll make a separate PR for the second comment.
Change:
this trade-off is important in deciding the effective anonymity of each client in the system. <ins> 8.2.1.1. Another option to allow a large number of servers in the ecosystem, while preventing the joining of a number of different tokens is for the client to maintain sharded "redemption contexts".  This would allow the client to redeem the tokens it wishes to use in a particular context, while still allowing the client to maintain a large variety of tokens from many servers.  Within a redemption context, the client limits the number of different servers used to a small number to maintain the privacy properties the client requires. As long as each redemption context maintains a strong privacy boundary with each other, the verifier will only be able to learn a number of bits of information up to the limits within that "redemption context". To support this strategy, the client keeps track of a "context" which contains the set of servers that redemptions have been attempted against.  An empty redemption is returned when the limit has been hit: </ins> 8.3. If there are multiple key registries, or if a key registry colludes

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
faster implementations?]] The table below lists parameters that meet these criteria at various <del> levels of security.  (Note that #1 is the field used in "Prio v2".) The "size" column indicates the number of bits required to represent elements of the field. </del> <ins> levels of security.  The "size" column indicates the number of bits required to represent elements of the field. </ins> [TODO: Choose new parameters for 2, 3, and 5 so that p is as close to 2^size as possible without going over. (4 is already close enough; 1

Discussion:
Remove terms which are infrequently used (and in a few cases, remove the unnecessary references) Clean up a few terms which appear to be defined incorrectly.
Change:
The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. <ins> An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP implementations MUST simply omit parameters in the IDENTICAL and TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. </ins> The "a=group:BUNDLE" attribute MUST include the mid identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

Discussion:
BUNDLE S 6.
I think we should hold this until Taylor's mmusic comments are resolved.
cf. URL
It doesn't seem like BUNDLE is going to change at this point; the disadvantages of using "bundle-only" in subsequent offers are that non-BUNDLE-aware middleboxes may be unhappy with a port of "0", and also, the answerer can't reject the offerer BUNDLE-tag section without rejecting the whole group (URL). I think the latter restriction is unnecessary (and it actually breaks some WebRTC max-bundle corner cases), but it doesn't sound like it's going to be changed. Speaking of which, if we're being thorough, we should address those corner cases. In "creating an answer", we should specify that if the answer rejects all the offerered m= sections with nonzero ports, it must also reject the m= sections with "a=bundle-only". So, if you're offered transceivers A, B and C with "a=bundle-only", and you do , the answer will reject A and B/C.
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best gueses is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
NAME NAME I think this should resolve it.
NAME this revised version needs your signoff + merge In an initial offer, if we want to communicate "this 'm=' section must be either bundled or rejected", that's accomplished with "a=bundle-only": a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 0 ... a=mid:B a=bundle-only In subsequent offers, this is accomplished by duplicating the IP address/port (see section 8.3.3): a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 10000 ... a=mid:B Is this initial vs. subsequent offer difference necessary? Both blobs of SDP are communicating the same information, so the "shared address" rules seem to only add complexity.

Also, the approach of using a "shared address" to communicate something isn't extensible to protocols that don't use an address for identification, like ICE. We'd need to define additional rules for those cases, or allow them specifically to use "a=bundle-only" in subsequent offers.
Change:
past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one.  Note that <del> any copies of previous or forked group states MUST be deleted </del> <ins> any copies of previous or forked group states must be deleted </ins> within a reasonable amount of time to ensure the protocol provides forward-secrecy.

Discussion:
According to I-D Nits: Checking nits according to URL : The abstract seems to contain references ([I-D.ietf-mls-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 557: 'URL forked group states MUST be deleted...'
TY!
Thanks NAME