jiebi/CodeConvo huggingface dataset:
Change:
Update messages SHOULD be sent at regular intervals of time as long as the group is active, and members that don't update SHOULD eventually be removed from the group.  It's left to the application <del> to determine an appropriate amount of time between Updates.  In general, however, applications should take care that they do not send MLS messages at a rate that overwhelms the transport over which messages are being sent. </del> <ins> to determine an appropriate amount of time between Updates.  Since the purpose of sending an Update is to proactively constrain a compromise window, the right frequency is usually on the order of hours or days, not milliseconds. The MLS architecture recommends that MLS be operated over a secure transport (see Section 7.1 of I-D.ietf-mls-architecture).  Such transport protocols will typically provide functions such as congestion control that manage the impact of an MLS-using application on other applications sharing the same network.  Applications should take care that they do not send MLS messages at a rate that will cause problems such as network congestion, especially if they are not following the above recommendation (e.g., sending MLS directly over UDP instead). </ins> Members are removed from the group in a similar way, as shown in remove-flow.  Any member of the group can send a Remove proposal

Discussion:
URL Thanks for working on this interesting topic. Thanks for Gorry fairhost for this TSVART review. I have few comments, which I believe if addressed will improve the document. - There is a mismatch between intended status of this spec (PS) and what in the doc header (Informational). I see Lars already have a discuss on it, so supporting it. - The specification says the UPDATE messages SHOULD be periodically sent and expects the applications to decided on the period between UPDATE messages. As I can see there are multiple implementations, can't we also recommend some guidelines and considerations on how to select the period? In some discussions I saw we were talking about hours and months.. - it says - "In general, however, applications should take care that they do not send MLS messages at a rate that overwhelms the transport over which messages are being sent." I am not sure I understand what "overwhelms the transport" means. Are we talking about the congestion control or bandwidth estimation part of transport protocols? Usually the application have no or very vague information about the internal protocol states, in that case how the applications are expected to take care of this? are we suggesting some interaction application rate control?
Change:
used in this section. For discovery, the resource types (rt) of the devices are important. <del> The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor.  The endpoints have names which are relevant to the light installation manager.  In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door.  The endpoint names reflect this physical location.  The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively.  The identifiers relevant to the RD are shown in endpoint below: It is assumed that the CT knows the RD's address, and has performed URI discovery on it that returned a response like the one in the discovery example. </del> <ins> The lamps in the luminaries have rt=tag:example.com,2020:light, and the presence sensor has rt=tag:example.com,2020:p-sensor.  The endpoints have names which are relevant to the light installation manager.  In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door.  The endpoint names reflect this physical location.  The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively.  The identifiers relevant to the RD are shown in endpoint below: It is assumed that the CT has performed RD discovery and has received a response like the one in the discovery example. </ins> The CT inserts the endpoints of the luminaries and the sensor in the RD using the registration base URI parameter (base) to specify the

Discussion:
These fix some missing parts from , and address Erik's SLAAC comments as well as their fall-out on the CTs "knowing" the RD.
Change:
7.4.1. <del> Once an IdP has generated an assertion, it is attached to the SDP offer/answer message.  This is done by adding a new 'identity' attribute to the SDP.  The sole contents of this value are a RFC4648 identity assertion.  For example: </del> <ins> Once an IdP has generated an assertion (see sec.request-assert), it is attached to the SDP offer/answer message.  This is done by adding a new 'identity' attribute to the SDP.  The sole contents of this value is the identity assertion.  The identity assertion produced by the IdP is encoded into a UTF-8 JSON text, then RFC4648 to produce this string.  For example: </ins> The 'identity' attribute attests to all "fingerprint" attributes in the session description.  It is therefore a session-level attribute.

Discussion:
The description of how an assertion is constructed seemed to imply that the object with the fingerprints was what went in a=identity. You had to read much further down to learn that this wasn't right and that it was really the assertion. This just moves some of the critical text up, duplicating it really, so that this confusion is less likely.
Change:
A local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. <del> A node that sends requests to servers and receives responses. </del> <ins> A node that sends requests to servers and receives responses.  In RESTful IoT systems it's common for nodes to have more than one role (e.g., both server and client; see sec-architecture). </ins> The state kept by a client between requests.  This typically includes the currently processed representation, the set of active

Discussion:
Note about client role and reference to architecture section for details.
+1 (if the newline in the definitions () still does render correctly...
How do you like your newlines cooked?
The definitions seem to render correctly. I'll merge this.
Change:
The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by sending a HTTP PATCH request to the WHIP resource URL with a body <del> containing a SDP fragment with mime type "application/trickle-ice- sdpfrag" as specified in RFC8840 with the new ice candidate or ice ufrag/pwd for ice restarts.  A WHIP resource MAY not support either trickle ICE (i.e.  ICE lite media servers) or ICE restart, and it MUST return a 405 Method Not Allowed for any HTTP PATCH request. </del> <ins> containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle ICE (i.e.  ICE lite media servers) nor ICE restart, and it MUST return a 405 Method Not Allowed for any HTTP PATCH request. </ins> A WHIP client receiving a 405 response for an HTTP PATCH request SHALL not send further request for ICE trickle or restart.  If the WHIP client gathers additional candidates (via STUN/TURN) after the <del> SDP offer is sent, it MUST send STUN request to the ICE candidates received from the media server as per RFC8838 regardless if the HTTP PATCH is supported by either the WHIP client or the WHIP resource. </del> <ins> SDP offer is sent, it MUST send a STUN request to the ICE candidates received from the media server as per RFC8838 regardless of the HTTP PATCH supported by either the WHIP client or the WHIP resource. </ins> 4.2.

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
3. <ins> MLS is designed to operate in the context described in I-D.ietf-mls- architecture.  In particular, we assume that the following services are provided: An Authentication Service (AS) that enables group members to authenticate the credentials presented by other group members. A Delivery Service (DS) that routes MLS messages among the participants in the protocol. MLS assumes a trusted AS but a largely untrusted DS. authentication- service-compromise describes the impact of compromise or misbehavior of an AS.  MLS is designed to protect the confidentiality and integrity of the group data even in the face of a compromised DS; in general, the DS is just expected to reliably deliver messages. delivery-service-compromise describes the impact of compromise or misbehavior of a DS. </ins> The core functionality of MLS is continuous group authenticated key exchange (AKE).  As with other authenticated key exchange protocols (such as TLS), the participants in the protocol agree on a common secret value, and each participant can verify the identity of the <del> other participants.  MLS provides group AKE in the sense that there can be more than two participants in the protocol, and continuous group AKE in the sense that the set of participants in the protocol can change over time. </del> <ins> other participants.  That secret can then be used to protect messages sent from one participant in the group to the other participants using the MLS framing layer or can be exported for use with other protocols.  MLS provides group AKE in the sense that there can be more than two participants in the protocol, and continuous group AKE in the sense that the set of participants in the protocol can change over time. </ins> The core organizing principles of MLS are _groups_ and _epochs_.  A group represents a logical collection of clients that share a common

Discussion:
This removes the following graf: The DS and AS may also apply additional policies to MLS operations to obtain additional security properties. For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations. MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted. MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. My sense is this belongs in Security Considerations, not here.
This looks good to me. Please do move the removed paragraph to the security considerations, either here or in .
Change:
If the client wishes to update this information in the future, it sends a POST request with updated information to the account URI. <del> The server MUST ignore any updates to the "key", or "order" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" field of the request before updating the account object. </del> <ins> The server MUST ignore any updates to "order" fields or any other fields it does not recognize. </ins> For example, to update the contact information in the above account, the client could send the following request:

Discussion:
The client knows what its public key is, because it has to have access to the private key in order to sign new-account requests or updates to the account resource. So this field serves no purpose.
Has this been discussed on list? I'm concerned that we're removing information that could be valuable for debugging client issues. There's no harm in keeping this; the server has to store this information anyway.
Yep, this was discussed on-list. I can say that as a client developer, I've never found this field useful. Clients need to be able to successfully serialize a jwk in order to speak the protocol. Also, I have no objection to servers including this as an extra field, but it seems wrong to normatively require it when it serves no purpose.
For the record where it was available for discussion. For me, the observation that you need the private key to get an account object is dispositive. There's not even debugging utility here. So I'm OK to merge. Right now, account objects echo back the public key associated with the account, in the "key" field. However, this is redundant since the only request types that can return an account object are signed by the corresponding private key, so the client necessarily knows what its public key is. Removing this simplifies the spec somewhat. URL Thoughts?
Change:
To ensure the confidentiality of E2E keys shared between endpoints, endpoints will make use of a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference.  That KEK, <del> defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKTKey, will be used to subsequently encrypt SRTP master keys used for E2E authenticated encryption (E2E Key(i); i={a given endpoint}) of media sent by a given endpoint. </del> <ins> defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKT Key, will be used to subsequently encrypt the SRTP master key used for E2E authenticated encryption of media sent by a given endpoint.  Each endpoint in the conference will create a random SRTP master key for E2E authenticated encryption, thus participants in the conference MUST keep track of the E2E keys received via the Full EKT Field for each distinct SSRC in the conference so that it can properly decrypt received media.  Note, too, that an endpoint may change its E2E key at any time and advertise that new key to the conference as specified in I-D.ietf-perc-srtp-ekt-diet. </ins> 4.3.

Discussion:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM
Change:
The following frame types defined in frame-types should be added to the "QUIC Frame Types" registry under the "QUIC Protocol" heading. <del> 11. </del> <ins> The following transport error code defined in tab-error-code should be added to the "QUIC Transport Error Codes" registry under the "QUIC Protocol" heading. 12. </ins> TBD <del> 12. </del> <ins> 13. </ins> TBD

Discussion:
If we want an MP specific error type we need to also add this to the IANA section.
Submitted PR for this issue. I just added MPPROTOCOLVIOLATION for connection close. If we have more specific error codes in the future, we can add them in the table.
Looks OK.
Change:
in the error response to clarify which claim couldn't be processed. Note that the Subject (sub) claim cannot always be verified when the <del> token is submitted to the RS, since the client may not have </del> <ins> token is submitted to the RS since the client may not have </ins> authenticated yet.  Also note that a counter for the expires_in (exi) claim MUST be initialized when the RS first verifies this token. When sending error responses, the RS MAY use the error codes from <del> section 3.1 of RFC6750, in order to provide additional detail to the client. </del> <ins> Section 3.1 of RFC6750, to provide additional details to the client. </ins> 5.8.1.2.

Discussion:
Based on the review by Steffi I updated the text in Section 5.8.1.1 "Verifying an Access Token".
Change:
with double quotes) in JSON texts. The syntax of Normalized Paths is restricted so that there is one and <del> only one way of representing any given Normalized Path.  Putting this another way, for any two distinct Normalized Paths, a JSON value exists that will yield distinct results when the Normalized Paths are applied to it. </del> <ins> only one way of identifying a given node.  Putting this another way, two distinct Normalized Paths are never equivalent to each other: there will always be at least one JSON value that yields distinct results when those paths are applied to it. </ins> Certain characters are escaped, in one and only one way; all other characters are unescaped.

Discussion:
There were picked up by NAME Improve table 1 Improve comparison examples Link to Boolean laws Make some examples shorter More list selector examples Compress two examples into one Clarify description of Normalized Paths
NAME The section concerning you needs more work, but I'm going to merge this PR with what we have and start a new one to improve that section.
NAME This should do it: URL
Change:
2.7. If the "Idempotency-Key" request header is missing for a documented <del> idempotent operation requiring this header, the resource server MUST reply with an HTTP "400" status code with body containing a link pointing to relevant documentation.  Alternately, using the HTTP </del> <ins> idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a link pointing to relevant documentation.  Alternately, using the HTTP </ins> header "Link", the client can be informed about the error as shown below. If there is an attempt to reuse an idempotency key with a different <del> request payload, the resource server MUST reply with a HTTP "422" </del> <ins> request payload, the resource server SHOULD reply with a HTTP "422" </ins> status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of RFC4918.  The server can also inform the client by using the HTTP header "Link" as shown below. If the request is retried, while the original request is still being <del> processed, the resource server MUST reply with an HTTP "409" status </del> <ins> processed, the resource server SHOULD reply with an HTTP "409" status </ins> code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. Error scenarios above describe the status of failed idempotent <del> requests, after the resource server prcocesses them.  Clients MUST correct the requests before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors. </del> <ins> requests after the resource server prcocesses them.  Clients MUST correct the requests (with the execption of 409 where no correction is required) before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors. </ins> For other 4xx/5xx errors, such as 401, 403, 500, 502, 503, 504, 429, or any other HTTP error code that is not listed here, the client

Discussion:
update my organization association & email id
NAME NAME pls review and merge this PR. We can publish the draft-02 after that.
looks like this one was merged already.
Change:
server also must have the token key. A non-shared-state Retry Service need only be configured with the <del> QUIC versions it supports.  A shared-state Retry Service also needs the token key, and to be aware if a NAT sits between it and the servers. </del> <ins> QUIC versions it supports, and an Allow- or Deny-List.  A shared- state Retry Service also needs the token key, and to be aware if a NAT sits between it and the servers. </ins> The following pseudocode describes the data items necessary to store a full QUIC-LB configuration at the server.  It is meant to describe

Discussion:
Hopefully this will close the gap between what we want Retry Services to do and reality.
It would help the anti-DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support. This provides a way to deploy new versions without having to upgrade the retry service software or hardware.
Change:
4.4. <del> Authtentication and authorization is supported by the Authorization HTTP header with a bearear token as per RFC6750. </del> <ins> Authentication and authorization is supported by the Authorization HTTP header with a bearer token as per RFC6750. </ins> 4.5.

Discussion:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!
Change:
proposed in subsec:varying would legitimize the usage of coding within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding <del> inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in CCSDS-131.5-O-1.  A research challenge would be on how such coding can be integrated in the IETF DTN stack. </del> <ins> techniques inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in CCSDS-131.5-O-1.  A research challenge would be on how such coding can be integrated in the IETF DTN stack. </ins> 5.

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