jiebi/CodeConvo huggingface dataset:
Change:
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for <del> an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </del> <ins> an endpoint to use a deployment-specific constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile- time constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new

Discussion:
attempt at addressing Warren's concern about the use of "globally"
You're right, the "globally" seems to be used in the sense of a "programming language", so the scope is a peer and the CID emitted by this peer for other peers to be used, when the other peers sends records to the emitting peer. Maybe we find a better term than "globally" to describe that.
maybe "sitewide"?
Change:
9.7. <del> IANA is asked to enter a new item into the Service Names and </del> <ins> IANA is asked to enter four new items into the Service Names and </ins> Transport Protocol Port Number Registry: <del> Service name: "core-rd" </del> <ins> Service name: "core-rd", Protocol: "udp", Description: "Resource Directory accessed using CoAP" </ins> <del> Protocol: "udp" </del> <ins> Service name "core-rd-dtls", Protocol: "udp", Description: "Resource Directory accedded using CoAP over DTLS" </ins> <del> Description: "Resource Directory accessed using CoAP" </del> <ins> Service name: "core-rd", Protocol: "tcp", Description: "Resource Directory accessed using CoAP over TCP" </ins> <del> Reference: this document </del> <ins> Service name "core-rd-tls", Protocol: "tcp", Description: "Resource Directory accedded using CoAP over TLS" All in common have this document as their reference. </ins> 10.

Discussion:
Those were in the original proposals during IETF / on the list, but not in the text yet. Depends on for practical merging purposes.
Change:
This section describes a variant of the issuance protocol in private- flow for producing publicly verifiable tokens.  It differs from the <del> previous variant in two important ways: </del> <ins> previous variant in that the output tokens are publicly verifiable by anyone with the Issuer public key. </ins> <del> The output tokens are publicly verifiable by anyone with the Issuer public key. </del> <ins> This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. </ins> <del> The issuance protocol does not admit public or private metadata to bind additional context to tokens. The first property means that any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. Beyond these differences, the publicly verifiable issuance protocol </del> <ins> Beyond this difference, the publicly verifiable issuance protocol </ins> variant is nearly identical to the privately verifiable issuance protocol variant.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens

Discussion:
From NAME issuance flow." Where does this metadata come up in the protocol? As far as I can tell, the two protocols look functionally equivalent modulo who can verify. Perhaps you removed metadata at some point? In particular, double check that the following claim in Section 6 is accurate: "The issuance protocol does not admit public or private metadata to bind additional context to tokens."
Change:
and is commonly deployed in many such systems.  In this context, "end-to-end" captures the notion that users of the system enjoy some level of security - with the precise level depending on the system <del> design - even when the messaging service they are using performs </del> <ins> design - even when the service provider they are using performs </ins> unsatisfactorily. Messaging Layer Security (MLS) specifies an architecture (this

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection behavior of the Transport System.  For example, a protocol- <del> specific property on the connection can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but MAY be used in this way by an implementation during connection establishment. </del> <ins> specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but MAY be used in this way by an implementation during connection establishment.  Connection Properties SHOULD be specified on a Preconnection prior to Connection establishment, but MAY be modified later.  Changes made to Connection Properties after establishment take effect on a best-effort basis. </ins> 4.1.3.

Discussion:
As discussed at the January interim last week
This definition is exactly right, IMO.Exactly right.
Change:
Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. <del> If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid "http-opportunistic" response for the origin as described in RFC8164 prior to making any such requests.  Other schemes might define other mechanisms. </del> <ins> For origins whose scheme is "http", an experimental method to accomplish this is described in RFC8164.  Other mechanisms might be defined for various schemes in the future. </ins> 3.3.

Discussion:
Text was already given the thumbs-up on the issue, so merging without waiting for review.
Section 3.2.2 states: "Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid http-opportunistic response for the origin as described in [RFC8164] prior to making any such requests. Other schemes might define other mechanisms." The first issue is that this text make normative use of RFC8164 to handle "http" scheme. RFC8164 is an experimental RFC. Thus we have a downref issue. I think it would be inappropriate to elevate RFC8164 status by allowing a downref here. I think one option would be to move the specification of the usage of RFC 8164 for the "http" URI scheme in HTTP/3 into its own experimental RFC. Another potential option is to simply inform about the ongoing experiment without specifying that it can be done with HTTP/3. Secondly, I am uncertain about the scope of the first sentence in that paragraph. Is there any other URI schemes other than "http" that this is applicable for? If it is which type of URI schemes is it applicable for? For clearly it is not applicable to the "rtsp" scheme that isn't using HTTP at all.
Second point first: HTTP doesn't restrict the scheme of URIs a client can request; URI schemes define what protocols can be used to access them, which might or might not include HTTP. For example, RFC7540 says: ":scheme" is not restricted to "http" and "https" schemed URIs. A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services. To the first point, I feel like not mentioning that RFC8164 can be done with HTTP/3 means it's irrelevant to include in this document, and the requirement to verify the peer can serve a scheme is necessary. Perhaps something like:
The proposed text looks good. I think that resolves it and you can move RFC8164 to be a informational ref. So I think this resolves my issue.
Based on this resolution, labeling this as "editorial"
Change:
The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the <del> legacy_cookie field in the ClientHello message SHOULD be set to a zero length vector (i.e., a single zero byte length field) and MUST be ignored by a server negotiating DTLS 1.3. </del> <ins> legacy_cookie field in the ClientHello message MUST be set to a zero length vector (i.e., a single zero byte length field). </ins> When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of

Discussion:
I can't reconcile: ... with: The MUSTs in these appear to be pulling in opposite directions. I suspect that the latter is correct though. It is possible that a DTLS 1.3 client could get a legacy cookie from a DTLS 1.2 server, so that it is valid for the legacy cookie to appear when supported_versions includes DTLS 1.3. However, that represents an attack and a DTLS 1.3 server shouldn't continue to establish the connection. Maybe it isn't a bad attack because the client doesn't change its posture in ways that would materially affect the resulting session, but we have generally tried to avoid these.
Change:
time.  A server can store the expiration time or include it in an encrypted form in the token. <ins> A token issued with NEW_TOKEN MUST NOT include information that would allow values to be linked by an on-path observer to the connection on which it was issued, unless the values are encrypted.  For example, it cannot include the previous connection ID or addressing information.  Information that allows the server to distinguish between tokens from Retry and NEW_TOKEN MAY be accessible to entities other than the server. </ins> It is unlikely that the client port number is the same on two different connections; validating the port is therefore unlikely to be successful.

Discussion:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG
Change:
This specification does not mandate a specific throttling behavior and implementers can adopt their preferred policies, including: <del> slowing down or preemptively backoff their request rate when </del> <ins> slowing down or preemptively back-off their request rate when </ins> approaching quota limits; consuming all the quota according to the exposed limits and then

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
network manager. At the moment of installation, the network under installation is not <del> necessarily connected to the DNS infra structure.  Therefore, SLAAC </del> <ins> necessarily connected to the DNS infrastructure.  Therefore, SLAAC </ins> IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below:

Discussion:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)
Change:
secure protocols to insecure protocols, or to weaker versions of secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is <del> not available, its connection will fail.  The Transport Services API MAY allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </del> <ins> not available, its connection will fail.  As described in equivalence, the Transport Services API can allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </ins>

Discussion:
URL This I believe is already covered in section 3.3. URL why this should not be moved to section 3.3 ?
Any thoughts here?
We did this intentionally to make sure the security considerations had the normative language there. I personally find it OK to have it both places. NAME are you OK with no change?
(We could of course note in one sentence that the requirements for security are provided in the security considerations section).
I added a reference back to 3.3, and made the MAY be a can. So that takes care of the second point. However, the first point with the cert reference I don't think is covered in 3.3, and should remain in security.
NAME
seems like I missed all the call out for me.. this has been strange that I don't get any emails about my mentions and comment's reply. This is only happening in case of TAPS github. anyway, changes are OK with me.
WFMlgtm
Change:
authorized to configure Appraisal Policy for Evidence in a Verifier. <del> [EDITORIAL NOTE] The term Attestation and Remote Attestation are not defined in this document, at this time.  This document will include pointers to industry uses of the terms, in an attempt to gain consensus around the term, and be consistent with the charter text defining this term. </del> 3. 4.

Discussion:
Removed incorrect text that said Remote Attestation was not defined in the doc. Moved Remote Attestation paragraph to the introduction section where I think it will (eventually) make sense in the context of introduction text. Signed-off-by: Dave Thaler
See comments in URL this term gets re-introduced here, without any annotation. The appraisal policy are the rules on how to test the evidence. Here, "Attestation" is the creation of the evidence Often people use the term "Attestation" to refer to the whole process. Suggestion that we should define this term somewhere, but maybe "Remote Attestation"? NAME FIDO has NONE-Attestation-Type, where there is no assessment. TCG would call this Implicit Attestation. URL NAME Let's take this to the WG, and maybe we can not get consensus on this term. NAME Charter says: "Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party."
PR added a paragraph defining Remote Attestation, and PR does some additional cleanup.
Can we close this issue now that PR and PR are merged?
yes
Change:
The following table defines the Handshake Context and MAC Base Key for each scenario: <del> The [sender] in this table denotes the sending side. </del> In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type and length fields.

Discussion:
NAME please double-check
URL The 1-RTT annotations are redundant and you also don't need [sender] in brackets because we can just fill in the values, as client/server have separate tables lines
Change:
4.2. Related to the foreseen virtualized network infrastructure, coding <del> schemes could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This trend can also be seen in cellular networks, making these discussions </del> <ins> techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This trend can also be seen in cellular networks, making these discussions </ins> extendable to other deployment scenarios I-D.chin-nfvrg-cloud-5g- core-structure-yang.  As one example, the coding VNF functions deployment in a virtualized environment is presented in I-D.vazquez-

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:
source of identity misbinding.  This is, however, entirely separable from the rest of the specification. <del> Transcript expansion also needs some analysis and we need to determine whether we need an extension to indicate that cTLS is in use and with which profile. </del> <ins> Once the handshake has completed, this specification is intended to provide a fully secured connection even if the client initially learned the template through an untrusted channel.  However, this security relies on the use of a cryptographically strong Finished message.  If the Finished message has not yet been received, or the transcript hash has been truncated by use of a small "finished_size" template element value, an attacker could be using a forged template to impersonate the other party.  This should not impact any ordinary use of TLS, including Early Data (which is secured by the previously completed handshake). </ins> 6.

Discussion:
LGTM.
Is it a design goal of this draft to support secure connection, even if the compression template is distributed over an untrusted channel? I believe it is a design goal, and I think it's probably achieved by the current draft (except for questions around the and keys), but it's not stated explicitly in the draft.
Change:
3.4.2. <del> A natural identifier to consider is the IP address of the User </del> <ins> A natural identifier type to consider is the IP address of the User </ins> Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness.

Discussion:
This rephrases the "Evaluating an Identifier" section (3.3) to refer to identifier types, rather than identifiers. We now draw the distinction between the type of an identifier, and an identifier itself, to avoid ambiguity. Fixes Issue
I'd appreciate it if a reviewer could go over the surrounding text to make sure the distinction is obvious, and we're not misusing the 'type' term.
A reviewer writes, I think we should rewrite this section to be about evaluating types of identifiers or sources of identifiers.
Agreed. It's ambiguous as to whether we're describe how to evaluate equals , or whether we're talking about the types (ip vs ethernet)
Not yet sure this is is all that's needed, but on its own it's clarifying I think.
Change:
When UDP is not available or well-supported on a network, IKEv2 may be encapsulated in TCP RFC8229. <del> 3.8.1.2. </del> <ins> 3.4.1.2. </ins> ESP is a protocol that encrypts and authenticates IPv4 and IPv6 packets.  The keys used for both encryption and authentication can be

Discussion:
Sort the protocols we describe based on perceived importance, popularity, etc. Basically, put non-standard ones at the end, and all else towards the front.
Correct!
I'm assuming the content itself hasn't changed, just moved around? It's not obvious from the diff, so LMK if not and I'll un-approve.