jiebi/CodeConvo huggingface dataset:
Change:
2. <del> This section uses the concept of ICE agent as define in RFC8445.  In the remainder of the document, it is assumed that each browser execution context has its own ICE agent. </del> <ins> This section uses the concept of ICE agent as defined in RFC8445.  In the remainder of the document, it is assumed that each browsing context (as defined in Section 7.1 of HTMLSpec) has its own ICE agent. </ins> 2.1.

Discussion:
PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.
Change:
An example of the COSE_Encrypt structure using the HPKE scheme is shown in hpke-example.  It uses the following algorithm combination: <del> AES-GCM-128 for encryption of the (detached) firmware image (at layer 0). </del> <ins> AES-GCM-128 for encryption of the (detached) firmware image. </ins> <del> AES-GCM-128 for encryption of the CEK in layer 1 as well as ECDH with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism (KEM). </del> <ins> AES-GCM-128 for encryption of the CEK as well as ECDH with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism (KEM). </ins> 7. The suit-cek-verification parameter contains a byte string resulting <del> from the encryption of 8 bytes of 0xA5 using the CEK. </del> <ins> from the encryption of 8 bytes of 0xA5 using the CEK with a nonce of all zeros and empty additional data using the cipher algorithm and mode also used to encrypt the plaintext. </ins> <del> [[Editor's Note: Guidance about the selection of an IV needs to be added here.]] </del> <ins> As explained in arch, the suit-cek-verification parameter is optional to implement and optional to use.  When used, it reduces the risk of an battery exhaustion attack against the IoT device. </ins> 8.

Discussion:
Based on discussions with Russ, I have updated the text in Section 7 about CEK Verification. Text about the parameters used for encryption were missing.
Change:
this approach allows unambiguous agreement between the endpoints on the protocol stack in use. <del> Note that given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name may lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </del> <ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </ins> 7. QUIC supports connection migration by the client.  If a lower-layer address changes, a QUIC endpoint can still associate packets with an <del> existing connection based on the Connection ID (see also connid) in the QUIC header, if present.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used.  As such if the client is known or likely to sit behind a NAT, use of a connection ID for the server is strongly recommended.  A non-empty connection ID for the server is also strongly recommended when migration is supported. </del> <ins> existing connection using the Destination Connection ID field (see also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. Use of a non-empty connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-empty connection ID is also strongly recommended when migration is supported. </ins> Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.
Change:
to a virtualized SATCOM terminals is the management of limited buffered equipments. <del> 4.3. </del> <ins> 4.4. </ins> In the context of the deep-space communications, establishing communications from terrestrial gateways to satellite platforms can

Discussion:
This section deserves a small introduction where you explain that you discuss a few topics, without trying to be exhaustive. Section 5.1 Are PEP part of "Network Functions"? What's their position in the architecture of Fig. 1?I don't understand why the question on code rate to use is in a challenge called "increased deployability". I'd rather put it in a challenge on dynamic adaptation (which is not identified).
Corrected and answered in PR
Change:
Choose a connection identifier C_R and store it for the length of the protocol. <del> Compute the transcript hash TH_2 = H(message_1, data_2) where H() is the hash function in the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> Compute the transcript hash TH_2 = H( H(message_1), data_2 ) where H() is the hash function in the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(message_1) can be computed and cached alredy in the processing of message_1. </ins> Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in

Discussion:
This addresses . I don't think we need to include names for the intermediary hashes.
Change:
IANA is requested to Create an entry, encrypted_server_name(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with <del> "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del> <ins> "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> 8.2.

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
implementation.  In particular, MD5 SLOTH and SHA-224 MUST NOT be used. <del> ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/ signature pairs.  However, the old semantics did not constrain the signing curve. </del> <ins> ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature pairs.  However, the old semantics did not constrain the signing curve.  If TLS 1.2 is negotiated, implementations MUST be prepared to accept a signature that uses any curve that they advertised in the "supported_groups" extension. Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3), MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. </ins> 4.2.3.

Discussion:
The document was pretty crisp about the version downgrade protections, but was less good about the changes to signature schemes. I have made a few changes to the description of signature_algorithms that should improve that. In particular, I have made it clear that the RSASSA-PSS codepoints are also defined for TLS 1.2 and that they can be used there. That means that TLS implementations need to be prepared to accept PSS signatures. This also adds a section that points to the pieces that 1.2 implementations need to consider.
(Well, I think, strictly speaking, we need only lock down HashAlgorithm.) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges. I'm not sure how to write that kind of IANA consideration or I'd put together a PR. The end result should probably be something like s/Unassigned/Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards, all new signature algorithms that apply to TLS 1.2 must go through a backported SignatureScheme. (If we're not happy with that strong of a restriction, we could perhaps only burn HashAlgorithms 0x80 and up. Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range. Though 's PSS text already implies we'll be backporting SignatureSchemes, so the division probably isn't necessary? I dunno. I don't really care either way.)
Let's just lock down HAshAlgorithm. Can you submit a PR?
Change:
message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and <del> DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM I-D.ietf-perc-double. RFC Editor Note: Please replace the values 0009 and 000A in the following two examples with whatever code points IANA assigned for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. </del> <ins> DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM RFC8723. </ins> Thus, the encoding on the wire presented here in network bytes order would be this stream of octets:

Discussion:
Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM
Change:
The set of ICE candidates and their parameters (a=candidate). <ins> The DTLS fingerprint(s) (a=fingerprint). </ins> The following modifications, if done by the browser to a description between createOffer/createAnswer and the setLocalDescription, MUST be honored by the browser:

Discussion:
Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM
Change:
the context of RESTful design for IoT systems.  For terminology of constrained nodes and networks, see RFC7228. <del> The state kept by a client between requests.  This typically includes the "current" resource, the set of active requests, the history of requests, bookmarks (URIs stored for later retrieval) and application-specific state. </del> A local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A node that sends requests to servers and receives responses. <ins> The state kept by a client between requests.  This typically includes the "current" resource, the set of active requests, the history of requests, bookmarks (URIs stored for later retrieval) and application-specific state.  (Note that this is called "Application State" in REST, which has some ambiguity in modern (IoT) systems where the overall state of the distributed application (i.e., application state) is reflected in the union of all Client States and Resource States of all clients and servers involved.) </ins> The practice of determining the "best" representation for a client when examining the current state of a resource.  The most common forms of content negotiation are Proactive Content Negotiation and

Discussion:
Addressing issue
Thanks Ari :) I will do a final pass and merge.
Originally, application state defined the state kept on the client, that is, what Web page is currently rendered and which pages were visited before. This does not make sense anymore when resource state is more than static Web pages, but parameters, physical state, etc. "Application state" logically would mean the state of the overall IoT application (state of the client and resoource state).
Related comment by Mike Amundsen:
I would add a comment in the definition, that this is called "Application State" in Fielding's thesis, but has some ambiguity in mordern (IoT) applications, where resource state is very dynamic and reflects part of the state in which the overall application is.
Change:
The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 5.4.2. </del> <ins> 5.5.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce"

Discussion:
As discussed (too ambiguously) at IETF 96, this refactor uses two nested JWS objects instead of one parallel JWS object. This preserves the pattern that every ACME message sent by the client is signed by exactly one account key, and saves clients from having to search through multiple signatures in the verification process.
Looking at the current mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now: It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key. Both signatures have to include the parameter, so this request burns two nonces unnecessarily The server's JWS checking code now has to switch between validating one signature and two Lots of JWS implementations don't support multiple signatures If not for this, we could require the flattened JSON serialization You need a lot of duplication to deal with the copy/paste attacks (cf. ). (On the other hand, I like that both signatures cover the parameter; reduces replayability.) I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.
Just noticed that if we keep to one signature per object, you can do nice stuff like this on the server:
Change:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Discussion:
and
whoops, didn't realize that eric hadn't reviewed before I merged. NAME want to take a quick look?
This updates 4572 so needs to be referenced. Also see URL
This changes the requirements around use of .
Dup of
Minor nits.
Change:
negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has <del> provided similar functionality since the introduction of RTMFP RFC7016 in 2008. </del> <ins> provided similar functionality since the introduction of Real-Time Media Flow Protocol (RTMFP) support RFC7016 in 2008. </ins> 4.

Discussion:
(nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." : It seems like the references for STUN and TURN should be normative.
Change:
Filter expressions "?<boolean expr>" select certain children of an object or array as in <del> 1.3.4. </del> <ins> 1.4.4. </ins> tbl-overview provides a quick overview of the JSONPath syntax elements.

Discussion:
The text will be adjusted in a future PR.
This github bug is slowing me down a bit:
Huh! I'm not seeing that.
I'm only seeing it every second time I try to pull the repo state (issues, PRs) into emacs, which seems to use a graphql API. Annoying. This used to work well...
Thanks!
Change:
These messages use a handshake content type and are encrypted under the application traffic key. <ins> Handshake messages sent after the handshake MUST NOT be interleaved with other record types.  That is, if a message is split over two or more handshake records, there MUST NOT be any other records between them. </ins> 4.4.1. At any time after the server has received the client Finished

Discussion:
No sender could possibly need to send half of a message interleaved with application data in TLS, so forbid this. This cuts down on the state-space a receiver needs to worry about. This also means one cannot force the peer to buffer all but one byte of a giant post-handshake message, and then never complete it for the lifetime of the connection. (Although it does not remove all steady state buffering DoS-type concerns.)
Change:
10.3. <del> Connectedness: Unconnected </del> <ins> Connectedness: Connectionless </ins> Data Unit: Datagram

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks <del> implied by the Connection's transport parameters.  The Message may also contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack dependent.  In particular, when this information is available, the value of the Explicit Congestion Notification (ECN) field is contained in such metadata. This information can be used for logging and debugging purposes, and for building applications which need access to information about the transport internals for their own operation. </del> <ins> implied by the Connection's transport parameters. </ins> The Message Object must provide some method to retrieve an octet array containing application data, corresponding to a single message

Discussion:
And add an early data metadata value.
I'll dig up relevant discussions from the TLS WG.
See, e.g.: URL
Looks like a good candidate for a read-only recv property…
NAME Aren't all receives read-only?
Looks good - minor nits noted in URL lgtmMuch better I think!
Change:
representation can be described by the CDDL I-D.ietf-cbor-cddl specification in mct-cddl: <ins> This format is intended as a strict specification: An implementation MUST stop processing the representation if there is a CBOR well- formedness error, a deviation from the structure defined above, or any residual data left after processing the CBOR data item.  (This generally means the representation is not processed at all except if some streaming processing has already happened.) </ins> 3. 3.1.

Discussion:
So, a multipart representation can be processed up till the first error? Works for me.
I think we have to avoid saying "must check the whole thing before acting on any of it". The intention was not to say "If there is an error, you have to process up to the error". Is that what you read there?
mmm, that's not how I interpret "stop processing". Maybe "invalidate processing"?
But that is too close the meaning I'm trying to avoid. Maybe we can leave it slightly open as it is proposed now?
Sorry I'm not following: Which meaning are you trying to avoid? I think not removing the ambiguity in the text is a bad thing.
Nice, thanks (and also, my previous ship-it is still valid).
Klaus still sees a problem with assigning too much leeway to the application in giving the positioning special semantics. We'll need to discuss this a bit further...
I don't see how we could limit applications in this sense? It's intrinsically a piece of malleable data. And what's more important, your change here only talks about what happens on syntactic violations, which is as far as we can go to limit application leeway.
Well, this is introductory material that tells readers how this is supposed to be used. I made a proposal that I think reflects Klaus' sentiment. In the process, I lost the part that needed the fix requested by , but I think that is OK -- an introduction should not really have a MUST anyway. NAME — better?
Apart from the array, set and struct-like use cases, it'd be worth mentioning the "union" pattern that was discussed at the interim?
LGTM
NAME do you want to re-integrate af472b3 here or prefer to merge as-is?
Since about 9 hours I'm trying to write the union sentence; crazy day.
And, yes, af472b3 should stay in, but I don't care in which PR :-)
If you like the wording of the union pattern, this can go in and we can submit the next version.
Go for it! FWIW I like it very much.
Klaus: Carsten seems to prefer failing hard and early (draft-iab-protocol-maintenance). Thomas loves simplicity and +1 Carsten's proposal.
Klaus has a point, but we already have a way to evolve: Define a new media type.

I don't think there really is a need here to haphazardly send a new version of this to someone that might not understand it.
+1, as I said in other emails, we don't need to make it perfect now. Let's make it simple, use it and measure its ergonomics. We can always grab another code point in the future if this needs fixing.
NAME wdyt?
sorry, hit the wrong button
LGTM
Change:
This alert is always fatal. <del> This alert was used in some earlier versions of TLS.  It MUST NOT be sent by compliant implementations.  This alert is always fatal. </del> The protocol version the peer has attempted to negotiate is recognized but not supported.  (For example, old protocol versions might be avoided for security reasons.)  This alert is always

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.
Change:
richer set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results. <del> The quality of the Attestation Results depend upon the ability of the Verifier to evaluate the Attester.  Different Attesters have a </del> <ins> The quality of the Attestation Results depends upon the ability of the Verifier to evaluate the Attester.  Different Attesters have a </ins> different _Strength of Function_ strengthoffunction, which results in the Attestation Results being qualitatively different in strength.

Discussion:
This is the portion of the complete review that contains minor/editorial changes aggregated in a single PR and various commits as discussed in the last editor meeting.
Are you sure that making Composite Device a term isn't a better idea?
I agree with that. There are also some other terms that I would capitalize. But this is the editorial part of the changes so I stuck with the groups consensus. Could you open an issue on "terms you want to capitalize"?
When I ask github to render the diff, it says that it can not. ("Oh my") it says. I wonder if there is an error in the markdown?