jiebi/CodeConvo huggingface dataset:
Code change:
The "welcome_info_hash" field contains a hash of the WelcomeInfo object sent in a Welcome message to the new member. <del> A group member generates this message by requesting a UserInitKey </del> <ins> A group member generates this message by requesting a ClientInitKey </ins> from the directory for the user to be added, and encoding it into an Add message.

Related discussion:
text: Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Code change:
Endpoints MAY implement additional filtering policies on the IP packets they forward. <del> 6. </del> <ins> 7. </ins> CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used. <del> 6.1. </del> <ins> 7.1. </ins> The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote

Related discussion:
text: Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric
Code change:
12. <ins> This document does not require any actions by IANA. 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, and Nancy Cam-Winget.

Related discussion:
text: Merged from draft-thaler-rats-URL Signed-off-by: Dave Thaler
PR and PR merged text that I had, and continue to have, problems with. A summary of the problems follows: 1) It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment. 2) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism). 3) time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear. 4) It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing might address this naturally, if it uses a different section title. 5) There are some editorial typos, such as capital "The" in the middle of a sentence, etc. 6) I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is. 7) time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this.
Code change:
12. <ins> This document does not require any actions by IANA. 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, and Nancy Cam-Winget.

Related discussion:
text: 8) The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.
Hopefully PR now addresses this issue.
PR reverts the text, leaving the work in progress in PR
fixed by .
Code change:
recipients can be encoded either this way or as a single array element. <del> A 'null' value if there are no recipients. </del> <ins> A 'nil' value if there are no recipients. </ins> 4.1.

Related discussion:
text: The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.
Code change:
6.2.3. <del> Stream types of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown types be ignored.  These streams have no semantics, and can be sent when application-layer padding is desired.  They MAY also be sent on </del> <ins> Stream types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored.  These streams have no semantics, and can be sent when application-layer padding is desired.  They MAY also be sent on </ins> connections where no data is currently being transferred.  Endpoints MUST NOT consider these streams to have any meaning upon receipt.

Related discussion:
text: Clarify reserved values for stream types, settings identifiers, frame types, and error codes. 0x1f N + 0x21 for the value of N = -1 is 0x02. Literal interpretation of the current text includes this as a reserved value. The parenthetical examples given in Section 11.2 make it clear that this was not the intention, rendering this PR editorial. The main motivation of this PR is not that the current text is inconsistent, but that parenthetical examples from 11.2 are necessary to correctly interpret the definitions in sections 6.2.3, 7.2.4.1, 7.2.8, and 8.1. Alternative wordings could be: "0x1f N + 0x21 for N = 0, 1, 2, ..." "0x1f N + 0x02 for positive integer values of N" "0x1f N + 0x02 for N = 1, 2, 3, ..." "0x21, 0x21 + 0x1f, 0x21 + 2 * 0x1f, ..." "a value of at least 0x21 with a remainder of 0x02 modulo 0x1f" "a value of at least 0x21 that is congruent to 0x21 modulo 0x1f" none of which is better than what this PR proposes.
Code change:
An instruction is a Service Discovery Instruction if it contains <ins> Note that there can be more than one Service Discovery Instruction for the same name if the SRP requestor is advertising more than one service of the same type, or is changing the target of a PTR RR.  For each such PTR RR add or remove, the above constraints must be met. </ins> 2.3.1.2. An instruction is a Service Description Instruction if, for the

Related discussion:
text: Update Service Discovery Instruction text to address Esko Dijk's last call comments. This fixes a bogus reference, removes a confusing double negative, and splits the text hierarchically in a way that hopefully makes more sense.
Code change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.

Related discussion:
text: I've had to make some changes in the template to deal with some odd regressions in CircleCI (see URL for details). This is the updated configuration.
Yeah, given how this breaks in Circle; that's probably wise.
NAME NAME do you think that you could stop following this project in CircleCI? Then we can merge this one.
Is there a reason not to simply move this repo over to GitHub Actions as well?
Code change:
HPKE algorithms that are used with that key. The identity of an oblivious proxy resource that will forward <del> encapsulated requests and responses to the oblivious request resource. </del> <ins> encapsulated requests and responses to a single oblivious request resource.  See proxy-state for more information about the mapping between oblivious proxy and oblivious request resources. </ins> This information allows the client to make a request of an oblivious target resource without that resource having only a limited ability

Related discussion:
text: This makes the choice of a 1:1 mapping clear: avoid being used as an open proxy through explicit configuration of your ACLs. cc NAME
The proxy has a fixed mapping. It's resource maps to just one request resource. That's a deliberate choice that we should probably be much more up front about.
Yes, I think this makes sense, but it took me a while to realize it when implementing. Having a section on mapping state on the proxy would be useful.
Vittorio says: This relates in particular to the potential for generic services with open destination (not a capability in the proposal) to be used for nefarious purposes (spamming, bot net command and control, hiding illegal activity, etc...).
Code change:
Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation. <del> 4.3. </del> <ins> 4.4. </ins> A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal

Related discussion:
text: Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler
Code change:
and changed with each message received by a client. However, the signature private keys are mostly used by clients to <del> send a message.  They also are providing the strong authentication guarantees to other clients, hence we consider that their protection by additional security mechanism should be a priority. </del> <ins> send a message.  They also provide strong authentication guarantees to other clients, hence we consider that their protection by additional security mechanisms should be a priority. </ins> <del> Overall there is no way to detect or prevent these compromise, as </del> <ins> Overall there is no way to detect or prevent these compromises, as </ins> discussed in the previous sections, performing separation of the application secret states can help recovery after compromise, this is the case for signature keys but similar concern exists for the

Related discussion:
text: For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.
Code change:
11.3. <del> It is important to delete all security sensitive values as soon as </del> <ins> It is important to delete all security sensitive values S as soon as </ins> they, or another value derived from them, is used for encryption or decryption.

Related discussion:
text: Update change log for draft-07 No conflicting PRs so I did break many lines that were too long. Fix a few minor editorial issues after merging the tree-based application key schedule.
Code change:
as far as the overall protocol is concerned. A single role need not be deployed as a monolithic service.  For <del> example, A client instance could have components that are installed </del> <ins> example, a client instance could have components that are installed </ins> on the end user's device as well as a back-end system that it communicates with.  If both of these components participate in the delegation protocol, they are both considered part of the client

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:
Code change:
resource returned by the initial registration operation. An update MAY update registration parameters like lifetime, base URI <del> or others.  Parameters that are not being changed SHOULD NOT be </del> <ins> or others.  Parameters that are not being changed should not be </ins> included in an update.  Adding parameters that have not changed increases the size of the message but does not have any other <del> implications.  Parameters MUST be included as query parameters in an </del> <ins> implications.  Parameters are included as query parameters in an </ins> update operation as in registration. A registration update resets the timeout of the registration to the

Related discussion:
text: The SHOULD is not an interoperability requirement but a quality-of-implementation level recommendation; the MUST could have been read as a requirement to have parameters there and is more describing mechanism than compatibility. See-Also: URL Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.
Code change:
Transport Properties: Transport Properties allow the application to express their requirements, prohibitions, and preferences and <del> configure the Transport System.  There are three kinds of </del> <ins> configure the Transport Services system.  There are three kinds of </ins> Transport Properties: Selection Properties (preestablishment) that can only be

Related discussion:
text: Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!
Code change:
section_capport_enforcement, until site-specific requirements have been met. <del> At this time we consider only devices with web browsers, with web </del> <ins> This document only considers devices with web browsers, with web </ins> applications being the means of satisfying Captive Portal Conditions. <del> An example interactive User Equipment is a smart phone. </del> <ins> An example of such User Equipment is a smart phone. </ins> The User Equipment:

Related discussion:
text: Multiple reviewers objected to the way in which we captured interactions with headless/UI-less devices. Clarify the document's intent. Do this by removing language that indicated that we would eventually get around to adding the requirements, and specify explicitly that we are not handling devices without UIs.
Eric points out in his review: He suggests as a solution: I propose we do this. The first mention is in section one. We can say something along the lines of "A future document could provide a solution for devices without user interfaces. This document focuses on devices with user interfaces."
On page 4: Joel Halpern writes,
We might want to avoid relying on the captivity concept so heavily, but this is a good change nonetheless.
Code change:
and/or received from a Remote Endpoint (i.e., a logical connection that, depending on the kind of transport, can be bi-directional or unidirectional, and that can use a stream protocol or a datagram <del> protocol).  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the Preconnection (i.e., peer to peer establishment; rendezvous). </del> <ins> protocol).  Connections are presented consistently to the application, irrespective of whether the underlying transport is connection-less or connection-oriented.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the Preconnection (i.e., peer to peer establishment; rendezvous). </ins> Once a Connection is established, data can be sent and received on it in the form of Messages.  The interface supports the preservation of

Related discussion:
text: Interface, Section 2, "A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection-establishment and closing". Should this be "…to datagram and stream-oriented transports"? At what point do we explain that and are also used for connectionless protocols? This change would finesse the question here, leaving it for Section 3, or we can restructure the draft to clarify earlier.
Yes to (1): Datagram protocols can be connection-oriented or not; however the point here seems to be either: /interface to datagram and stream-oriented transports/ or /interface to both connection-less and connection-oriented transports/ ... I'd favour the first, it's clear enough and doesn't use terms that we later re-use. Also to (2): I think we could insert a specific sentence after: " A Connection represents an instance of a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). " That explicitly says something like: "This connections are presently consistently to the application, irrespective of whether the underlying transport is connection-less and connection-oriented."
Code change:
A client MUST NOT send a DUPLICATE_PUSH frame.  A server MUST treat the receipt of a DUPLICATE_PUSH frame as a connection error of type <del> HTTP_MALFORMED_FRAME. </del> <ins> HTTP_UNEXPECTED_FRAME. </ins> The DUPLICATE_PUSH frame carries a single variable-length integer that identifies the Push ID of a resource that the server has

Related discussion:
text: I believe UNEXPECTED_FRAME is the preferred type.
I actually prefer the wording in duplicate push section and wonder if we should port that to PUSH_PROMISE too