jiebi/CodeConvo huggingface dataset:
Change:
Section 11.3 of RFC7252 (where an attacker would put a victim's address in the source address of a CoAP request).  For this purpose, the server MAY ask a client to Echo its request to verify <del> its source address.  This needs to be done only once per peer, and </del> <ins> its source address.  This needs to be done only once per peer and </ins> limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. <ins> A server may want to verify the aliveness of a client by responding with an Echo option. </ins> 3. The Request-Tag is intended for use as a short-lived identifier for

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
with a timer; at this point, the application could reapply the existing remote description as a final answer. <del> 3.5.2. </del> <ins> 3.6.2. </ins> Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
6.1.2. <del> Once a later packet has been acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past.  The time threshold is computed as kTimeThreshold * max(SRTT, latest_RTT).  If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time multiplier, is 9/8. </del> <ins> Once a later packet packet within the same packet number space has been acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past.  To avoid declaring packets as lost too early, this time threshold MUST be set to at least kGranularity.  The time threshold is: ~~~ kTimeThreshold * max(SRTT, latest_RTT, kGranularity) ~~~ If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. </ins> Using max(SRTT, latest_RTT) protects from the two following cases:

Discussion:
From a full read en route to Prague.
Thanks Jana, suggestions taken and "Clearer Loss Epoch" rewritten.
Change:
Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several ways in which an on-path attacker can learn private information about the connection.  The <del> cleartext Server Name Indication (SNI) extension in ClientHello </del> <ins> plaintext Server Name Indication (SNI) extension in ClientHello </ins> messages, which leaks the target domain for a given connection, is perhaps the most sensitive information unencrypted in TLS 1.3. The target domain may also be visible through other channels, such as <del> cleartext client DNS queries, visible server IP addresses (assuming </del> <ins> plaintext client DNS queries, visible server IP addresses (assuming </ins> the server does not use domain-based virtual hosting), or other indirect mechanisms such as traffic analysis.  DoH I-D.ietf-doh-dns- over-https and DPRIVE RFC7858 RFC8094 provide mechanisms for clients

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this model, the <del> attestation sequence is a two step procedure.  In the first step, an Attester conveys Evidence to a Verifier which compares the Evidence </del> <ins> attestation sequence is a two-step procedure.  In the first step, an Attester conveys Evidence to a Verifier, which compares the Evidence </ins> against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and

Discussion:
fix some typos and optimize the newly added diagrams to adapt to the width limitation
Thanks Wei! My humongous backlog told me "you'll fix this later" and now you did. Awesome!
Change:
A URL for the certificate that has been issued in response to this order. <del> The elements of the "authorizations" array are immutable once set, except for their "status" fields.  If any other part of the object changes after the object is created, the client MUST consider the order invalid. </del> <ins> The elements of the "authorizations" array are immutable once set. If any change is made to the array after the object is created, the client MUST consider the order invalid. </ins> The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue,

Discussion:
As discussed at IETF 97, this PR removes the "requirements" abstraction, and changes the "requirements" field in an application/order object to be an "authorizations" field. This is a replacement for .
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
risk is created by allowing calls at all from a page fetched over HTTP. <del> Even if calls are only possible from HTTPS sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page finer-grained.  Thus, it is also </del> <ins> Even if calls are only possible from HTTPS [RFC2818] sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page finer-grained.  Thus, it is also </ins> dangerous to allow WebRTC functionality from HTTPS origins that embed mixed content.  Note: this issue is not restricted to PAGES which contain mixed content.  If a page from a given origin ever loads

Discussion:
I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.
Change:
acknowledgements) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the <del> application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del> <ins> application. </ins> However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are

Discussion:
URL must be postprocessed to become metrics.
Waiting for more reviews, e.g. from NAME before we can merge.
The text describes an example for measuring the average RTT. I like that, but I think we should call out a little that the mean RTT is only one metric. When looking at management info, I'm often interested in min/max and variance... So: “A simple linear smoothing... to get a more stable estimate”. Quite so for a table average RTT. I’d prefer it if we could say something about RTT variance at this point. To me it is important that RTT measurements are clear, and we should never assume in a Spec that RTT is something specific, but more generally an estimate that needs to consider the variance.
Change:
with a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] <ins> An opaque byte string whose contents depend on the version of the structure.  For this specification, the contents are an ESNIConfigContents structure. The ESNIConfigContents structure contains the following fields: </ins> The non-empty name of the entity trusted to update these encryption keys.  This is used to repair misconfigurations, as described in handle-server-response.

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.
Change:
Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer- <del> directory. </del> <ins> directory; see wkuri-reg for the registration information for this well-known URI. </ins> 4.

Discussion:
While we're here, I'd like to recommend we align the name of this well-known value to align with the request/response names. In particular, what do folks think about "/well-known/private-token-issuer-directory"?
you're probably missing a registration for your well-known in the IANA considerations, the registry is URL
Change:
Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension). <del> Removing the EarlyDataIndication early-data-indication extension if one was present.  Early data is not permitted after HelloRetryRequest. </del> <ins> Removing the "early_data" extension (early-data-indication) if one was present.  Early data is not permitted after HelloRetryRequest. </ins> If a server receives a ClientHello at any other time, it MUST send a fatal "unexpected_message" alert and close the connection.

Discussion:
ClientHello mentions that earlydata should be removed, but earlydata doesn't mention it. Editorial.
Change:
Upon joining the system, each Client stores its initial cryptographic key material with the DS.  This key material represents the initial contribution from each member that will be used in the establishment <del> of the shared group key.  This initial keying material MUST be </del> <ins> of the shared group key.  This initial keying material is </ins> authenticated using the Client's identity key.  Thus, the Client stores:

Discussion:
Removing 2119 "MUST" as agreed in Paris. Note that this is the minimal change and in another PR I will suggest removing as many lower case instances of must, should, etc. as possible.
Change:
The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that <del> were sent on different paths.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </del> <ins> were sent on different paths when using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </ins> ACK_MP frame is formatted as shown in fig-mp-ack-format.

Discussion:
When negotiating the use of a single packet number space, it is not clear whether the use of ACKMP frame is acceptable or not. Should we only stick to ACK frames and consider reception of ACKMP frames to be MPPROTOCOLVIOLATION error? Or should we tolerate their reception if the packet number space identifier is 0?
Ah good point. I moved the text about ACKMP this morning because I assumed that you would only implement this frame if you use multiple packet number spaces. If that's the case receiving an ACKMP with enablemultipath=2 should be a PROTOCOLVIOLATION and we should specify that.
Look good to me.
Change:
API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. <ins> HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration

Discussion:
we can provide a reminder that http is stateless and therefore reordering happens so don't use doh for a session protocol.
Change:
receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the intermediary MUST treat it as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR.  The <del> Context ID field is optional and its use is negotiated end-to-end, see register-no-context-capsule.  Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </del> <ins> Context ID field is optional and whether it is present or not is decided end-to-end by the client, see register-no-context-capsule. Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </ins> Endpoints parse both the Quarter Stream ID field and the Context ID field in order to associate the QUIC DATAGRAM frame with a stream and

Discussion:
It doesn't appear that the peer has any say in the allocation of context IDs. If not, they're not really "negotiated." Perhaps better to say that they are "declared" or merge with "allocated."
Change:
SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 <del> and layer-1 encapsulations.  PEP could host coding mechanisms and </del> <ins> and layer-1 encapsulations.  PEP could host coding techniques and </ins> thus support the use-cases that have been discussed in this document. Deploying coding schemes at the TCP level in these equipment could be

Discussion:
A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.Typo: s/to cope from/to cope with/
We have updated the introduction structure and changed the usage of coding in the whole document. We hope this is better. cf PR and PR
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
"In this context, this document aims at identifying opportunities for further usage of coding in these systems." again, network coding. this pretending that link and channel FEC don't exist and that "coding", i.e. network coding, is somehow new is irksome.
Closed by PR
Change:
The OSCORE_Security_Context is a CBOR map object, defined in oscore- sec-ctx.  This object is transported in the 'cnf' parameter of the access token response as defined in Section 3.2 of I-D.ietf-ace- <del> oauth-params, as value of a field named 'osc' registered in osc-cwt and osc-jwt.  The master secret MUST be communicated as the 'ms' </del> <ins> oauth-params, as the value of a field named 'osc', registered in osc- cwt and osc-jwt.  The master secret MUST be communicated as the 'ms' </ins> field in the 'osc' field in the 'cnf' parameter of the access token response as defined in Section 3.2 of I-D.ietf-ace-oauth-params.  The AEAD algorithm may be included as the 'alg' parameter in the

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.
Change:
flooding the PE MUST drop the packet. When a TSN entity of the PE receives a packet from the DetNet Service <del> Proxy, it MUST first check via Stream Identification whether the packet belongs to a configured TSN Stream.  If no Stream ID is matched then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions MUST be executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </del> <ins> Proxy, it MUST first check via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream.  If no Stream ID is matched then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions MUST be executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.). Source MAC lookup MAY also be used for local MAC address learning. </ins> If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
4. <del> TBD: Define a media type for JSONPath expressions. </del> <ins> 4.1. IANA is requested to register the following media type RFC6838: Person & email address to contact for further information: iesg@ietf.org </ins> 5.

Discussion:
I merged this so once we have published an I-D with this change in it we can initiate the necessary review on the media-types list.
Looks plausible.