jiebi/CodeConvo huggingface dataset:
Change:
see <del> The syntax and semantics of fragment identifiers specified for +yaml SHOULD be as specified for application-yaml The syntax and semantics for fragment identifiers for a specific "xxx/yyy+yaml" SHOULD be processed as follows: For cases defined in +yaml, where the fragment identifier resolves per the +yaml rules, then process as specified in +yaml. For cases defined in +yaml, where the fragment identifier does not resolve per the +yaml rules, then process as specified in "xxx/yyy+yaml". For cases not defined in +yaml, then process as specified in "xxx/yyy+yaml". </del> <ins> Differently from "application/yaml", there is no fragment identification syntax defined for +yaml.  A specific "xxx/ yyy+yaml" media type needs to define the syntax and semantics for fragment identifiers because the ones in application-yaml do not apply unless explicitly expressed. </ins> See

Discussion:
no default frag-id for +yaml media types have to explicitly declare syntax and semantics
Compile fragment identifier section [ ] for [x] for ? Can we pospone this?
It seems strange to me that a media type would define a new "language" intrinsic.
I believe the registration should include the fragment identifier. +json does not identify one, which creates problems. It probably should have a registration update to address it. Not registering fragment handling means that a reference to a YAML-borne schema cannot be referenced. The part beyond the # would be formally nonsensical (as it is today). We can take some inspiration from the work on the same issue for JSON Schema. JSON Pointer tells us how to craft fragments. The same format applies to the semantic equivalent in YAML documents. I'll put in a pull request.
NAME we have splitted the two documents. I think that yaml fragment identifiers should probably be delegated to "structured" media types since there are multiple possibilities (eg. json-path, json pointers, ...) WRT openapi+yaml for example, we can state that the fragment uses json pointers.
NAME Can you confirm that the YAML community agrees with the current statement wrt fragment identifiers?
I'm pretty sure that fragment identifiers should not be defined for at least for now. As demonstrated e.g. by the work going on even in this repo, YAML is used to represent multiple different forms of structured data, some of which may at times be represented by other formats, such as JSON. So while YAML 1.1 and 1.2 do explicitly support on nodes that would rather naturally work as fragment identifiers, there's somewhat significant risk that this would complicate usage with sub-formats that natively use different methods, such as JSON Pointers. On the other hand, defining fragment identifiers for to follow the YAML spec for referring to anchors would make sense.
FWIW, I completely agree.
The choice to leave the fragment identifier of the structured syntax suffix to the media type is sensible: I will PR that.
Change:
Comparisons are restricted to Singular Path values and primitive values (such as number, string, "true", "false", "null"). <del> Data types are not implicitly converted in comparisons.  So ""13 == '13'"" selects no node. A member or element value by itself in a Boolean context is interpreted as "false" only if it does not exist.  Otherwise it is interpreted as "true".  To be more specific about the actual value, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with structured values. </del> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". "true", "false", and "null" are lower-case only (case-sensitive). <del> Regular expression tests can be applied to JSON string values (RFC8259) only (on the left-hand side of "=~"); they yield false otherwise. </del> The syntax of regular expressions in the string-literals on the right-hand side of "=~" is as defined in I-D.draft-bormann-jsonpath- iregexp.

Discussion:
Fixes URL
Let's continue in URL
Currently the syntax section of the "Filter Selector" section describes some semantics. These descriptions should be folded into the semantics section.
I'm not sure we are done with this yet. See comments.The reordering looks good to me.
Change:
? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e., <del> ID_CRED_R = { 4 : kid_R }, then only the byte string is included in the plaintext, represented as described in bstr- repr, see examples in id_cred. </del> <ins> ID_CRED_R = { 4 : kid_R }, then the compact encoding is applied, see compact-kid. </ins> Compute KEYSTREAM_2 as in expand, where plaintext_length is the length of PLAINTEXT_2.  For the case of plaintext_length

Discussion:
Clarification of the optimization of ID_CRED for 'kid',
Merging to include in -18
In , there is I would have expected this to be as per or have I missed something? There is a degree of ambiguity in ` is this refers to the byte string, not necessarily the subset integer equivalent, but the lake-traces would still appear to be wrong.
NAME That looks like a bug. As you can see further down in the same section: ( ? PAD2, IDCREDR / bstr / -24..23, SignatureorMAC2, ? EAD2 ) 32 48 d0 d1 a5 94 79 7d 0a af which is IDCREDR followed by 9 bytes CBOR encoding of SignatureorMAC2. We should also clarify to avoid the ambiguity. Thanks!
I removed the label so we don't forget to also clarify in the spec.
I was too quick making a change in -traces which I had to revert. The implementation is right (of course). So I made a clarification in -edhoc instead, see . Please review.
NAME PR is now merged. Let us know if you have any further comments.
Thanks for the update. When I have some spare time, I am doing a libcoap port. I have now got as far as doing Message_2 as per the traces.
Cool, keep us updated on the progress and if you are interested in interop-testing. Closing this issue then.
Change:
At the moment of installation, the network under installation is not necessarily connected to the DNS infrastructure.  Therefore, SLAAC <del> IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below: </del> <ins> IPv6 addresses are assigned to CT, RD, luminaries and the sensor. The addresses shown in interface-S below stand in for these in the following examples. </ins> In rd-en the use of RD during installation is presented.

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:
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only <del> possible when connection IDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </del> <ins> possible when CIDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </ins> The C bit (0x10) is set if the Connection ID is present.

Discussion:
In both versions of DTLS we have to do the extension negotiation because you have to agree on the CID values. In both versions we have to carry the CID in the record layer (if the CID is used). The way we incorporated the CID into the headers is different between the different versions. In DTLS 1.3 we have this variable length header and in DTLS 1.2 we don't. There are also privacy differences.
I'm inclined not to add anything here. If you feel strongly maybe you could provide a PR?
I think the privacy differences (and ability to change values over the lifetime of an association, e.g., when roaming) are probably worth mentioning. NAME do you plan to write some text? If not I can try to squeeze it in.
PR is available at
Fixed in . Closing.
LGTM
Change:
discretionary as, depending on circumstances, they could interfere with or prevent legitimate uses. <del> Services offered over loopback interfaces (that is, the IPv6 address ::1 or the IPv4 address 127.0.0.1) often lack proper authentication. Endpoints MAY prevent connection attempts or migration to a loopback address.  Endpoints SHOULD NOT allow connections or migration to a loopback address if the same service was previously available at a different interface or if the address was provided by a service at a non-loopback address.  Endpoints that depend on these capabilities could offer an option to disable these protections. </del> <ins> Services offered over loopback interfaces often lack proper authentication.  Endpoints MAY prevent connection attempts or migration to a loopback address.  Endpoints SHOULD NOT allow connections or migration to a loopback address if the same service was previously available at a different interface or if the address was provided by a service at a non-loopback address.  Endpoints that depend on these capabilities could offer an option to disable these protections. </ins> Similarly, endpoints could regard a change in address to link-local address RFC4291 or an address in a private use range RFC1918 from a

Discussion:
Text says >Services offered over loopback interfaces (that is, the IPv6 address ::1 or the IPv4 address 127.0.0.1) often lack proper authentication. On v4, loopback is technically the entire 127.0.0.0/8 network, not just that one address. But I wonder if we need the parenthetical anyway?
Change:
including total DoS attacks (where it simply refuses to forward any messages) and partial DoS attacks (where it refuses to forward messages to and from specific Clients).  As noted in delivery- <del> guarantees, these attacks are only partially detectable by clients. Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology. </del> <ins> guarantees, these attacks are only partially detectable by clients without an out-of-band channel.  Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology. </ins> Because the DS is responsible for providing the initial keying material to Clients, it can provide stale keys.  This does not

Discussion:
Remove "join an existing group" from architecture doc, based on UserAdd having been removed from the protocol doc. Remove statement that message delivery cannot be correlated between AS identities and DS delivery channels. This seems generally very difficult to achieve. It may be possible at times, but does not seem to be grounded in discussions that we have had at the working group meetings. Note that federation requires compatible wire encodings. Note that communication with the AS requires TLS or alternative authentication. Note that out-of-band channels may facilitate detection of misbehaviour. Some grammar fixes.
Change:
before or during Connection establishment, see also msg- safelyreplayable.  It is given in Bytes. <del> 7.1.9.2. </del> <ins> 7.1.10.2. </ins> singularTransmissionMsgMaxLen

Discussion:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.
Change:
Note: This is a different construction from that in TLS 1.2, which specified a partially explicit nonce. <del> The plaintext is the TLSPlaintext.fragment. </del> <ins> The plaintext is the concatenation of TLSPlaintext.fragment and TLSPlaintext.type. </ins> The additional authenticated data, which we denote as additional_data, is defined as follows:

Discussion:
This pull request has been updated to the current master
Consensus at meeting to merge this PR with updates and with the dummy type byte restored. NAME has action item to actually measure whether we can strip off the now fixed type, record.version bytes.
I've updated this with the expected changes: dummy external ContentType octet is restored, and URL is after fragment.content instead of the other way around (to make it easier to encrypt without having to shuffle buffers).
I agree with davegarrett's suggestion about field naming here, and have supplied a change implementing it.
TLSCiphertext.recordversion provides no useful information, encourages implementations to check it unnecessarily, and wastes two bytes per record. It should be removed entirely. This is effectively dependent on PR or similar changes. Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion. Edited to add: Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06. The TLSPlaintext equivalent of this version field cannot be removed as it is required for backwards compatibility, however it's only used with ClientHello at this point.
Defer pending measurements. Note that this fate shares with removing the cleartext content type
sgtm Amending issue title.
Mozilla is working on measurements.
Change:
Limited flow confidentiality. <del> 3.8.3. </del> <ins> 3.4.3. </ins> <del> 3.8.3.1. </del> <ins> 3.4.3.1. </ins> Availability of UDP to negotiate, or implementation support for TCP-encapsulation.

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.
Change:
management, control the reduction of water losses and improve the city water system through Edge computing. <del> 7.2.4. </del> <ins> 6.2.4. </ins> T.B.D. <del> 7.2.5. </del> <ins> 6.2.5. </ins> T.B.D. <del> 7.2.6. </del> <ins> 6.2.6. </ins> T.B.D. <del> 8. </del> <ins> 7. </ins> T.B.D. <del> 9. </del> <ins> 8. </ins> The authors would like to thank Joo-Sang Youn and Akbak Rahman for their valuable comments and suggestions on this document.

Discussion:
Main change: Merged 2 sections (IoT Integrated with Edge Computing and architecture section) into a new "model" section. Updated the architecture diagram into a model diagram including the logical functions proposed by Dirk. Heavily reworded/simplified text from the previous 2 sections - I tried to keep relevant info, but removed what was redundant with the existing challenges section. The architectures (gateway vs. distributed) are shortly listed above the figure, but the rest aims to be general. Some renaming for your consideration (feel free to ignore/change): new draft title: IoT Edge Computing Challenges, Model and State-of-Art Review challenges section ("new IoT challenges" could seem a bit general): Challenges for IoT and Impacts of Edge Computing Minor: edits in abstract
Yong-Geun, Jungha, and Dirk agreed via e-mail. Since the new version has been sent to the Datatracker, I will merge.
Change:
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the <del> Partial IV (Sequence Number) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </del> <ins> Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </ins> Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the

Discussion:
This should fix issue
As per Christian Amsüss' message from 2017-01-04 we should clarify how we expect implementers to map sequence numbers to partial IV's. I think that network-byte order is a good way.
Change:
The signature keys are exchanged out of band along the secret keys. <ins> 3.5. 3.5.1. Each SFrame session uses a single ciphersuite that specifies the following primitives: o A hash function This is used for the Key derivation and frame hashes for signture.  We recommend using SHA256 hash function. o An AEAD encryption algorithm [RFC5116] While any AEAD algorithm can be used to encrypt the frame, we recommend using algorithms with safe MAC truncation like AES-CTR and HMAC to reduce the per-frame overhead.  In this case we can use 80 bits MAC for video frames and 32 bits for audio frames similar to DTLS-SRTP cipher suites: 1- AES_CM_128_HMAC_SHA256_80 2- AES_CM_128_HMAC_SHA256_32 o [Optional] A signature algorithm If signature is supported, we recommend using ed25519 3.5.2. SRTP is used as an outer encryption, since the media payload is already encrypted, and SRTP only protects the RTP headers, one implementation could use 4 bytes outer auth tag to decrease the overhead, however it is up to the application to use other ciphers like AES-128-GCM with full authentication tag. It is possible that future versions of this draft will define other ciphers. </ins> 4. SFrame must be integrated with an E2EE key management framework to

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
Peer authentication extensibility based on shared secret, certificates, digital signatures, or EAP methods. <del> 3.8.2.2. </del> <ins> 3.4.2.2. </ins> Data confidentiality and authentication.

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.
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 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </ins> This document defines requirements on future QUIC versions, even where normative language is not used.

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code outside the 2xx range. <del> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del> <ins> HTTP endpoints SHOULD use the Capsule-Protocol header field to simplify intermediary processing.  Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY alter this recommendation. </ins> 3.5.

Discussion:
The text of the draft currently defines how the header works, but there's no RFC 2119 text explaining whether the client MUST or MAY send it (and the corresponding receiver behavior in case the header is missing).
The draft currently states - right now it's up to CONNECT-UDP / WebTransport, etc to define this normative text. Is that acceptable?
Sure, but it's not clear from the current text that the drafts have to give the specific guidance about the use of the header (the WebTransport draft currently does not).
Fair enough. I suggest we replace that sentence with something along the lines of:
Change:
the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a <del> NAT64 scenario), or may not be usable for some other reason (e.g., a candidate that contains a FQDN that fails to resolve). </del> <ins> NAT64 scenario), or may not be usable for some other reason. </ins> In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE

Discussion:
I committed the change.
WHERE: All Candidates Discarded WHAT: Remove/rewrite the following: "(e.g., a candidate that contains a FQDN that fails to resolve)." WHY: It is unclear whether how/if FQDNs can be used in candidates. I think the text saying that the candidate cannot be used for some other reason is enough.
Implemented in One issue, though: The text says: "One consequence of this behavior is that in cases where ICE should fail, e.g., where both sides provide candidates with unsupported address families ICE will no longer fail immediately, and only fail when the aforementioned timer expires." ('unsupported address families' used to be 'unresolvable FQDNs', but the issue is the same) Q: If both endpoints provide candidates that can't be used, how is the timer going to help? No endpoint will send any connectivity checks, so there will be no peer-reflexive candidates.
LG with one minor text change
Change:
restrictions) MUST be compatible with the selected key exchange algorithm. <del> The "server_name" and "trusted_ca_keys" extensions TLSEXT are used to guide certificate selection. </del> <ins> The "server_name" and "trusted_ca_keys" extensions RFC6066 are used to guide certificate selection. </ins> If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/

Discussion:
The TLS 1.2 RFC cited WIP extension definitions at time of publish. Update current draft to point the final RFC 6066.
URL Fix merged. This should be closable now.
Change:
5. <ins> An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses. </ins> Different response media types will provide more or less information from a DNS response.  For example, one response type might include the information from the DNS header bytes while another might omit

Discussion:
Thats better. Thanks
It would be good to explicitly call out the DNS rcode SERVFAIL as a type of failure response as well, not just NXDOMAIN, as they are very different sorts of failures such that the latter can be considered, in some contexts, as not really a failure.
the merged patch URL no longer mentions specific rcodes at all.. wdyt?
I personally think that as a DNS implementer that there is enough ambiguity around understanding a valid DNS response, a negative answer, and a failure response, that it should be made more painfully clear that something like all DNS servers returning message-valid SERVFAILs still warrants an HTTP 2xx.
Agree with NAME .
will reopen the issue to add more text
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
Liked Martin's rewording for the response text, but removed the security considerations until further discussion. Patrick, please edit or pull.
Change:
ClientHelloOuter also contains the "encrypted_client_hello" extension.  If not, it MUST abort the handshake with a "missing_extension" alert.  Otherwise, it checks that <del> ClientECH.cipher_suite is unchanged, and that ClientECH.config_id and ClientECH.enc are empty.  If not, it MUST abort the handshake with an "illegal_parameter" alert. </del> <ins> ClientECH.cipher_suite and ClientECH.config_id are unchanged, and that ClientECH.enc is empty.  If not, it MUST abort the handshake with an "illegal_parameter" alert. </ins> Finally, it decrypts the new ClientECH.payload as a second message with the previous HPKE context:

Discussion:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.