jiebi/CodeConvo huggingface dataset:
Change:
mitigated by including the signature algorithm identifier in the data to be signed. <ins> 8.2. I-D.irtf-cfrg-eddsa describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves.  The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing and, HashEdDSA where a hash function is applied to the content before signing and the result of that hash function is signed.  For use with COSE, on the pure EdDSA version is used.  This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature.  Thus, the use of an incremental update process would not be useful.  Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE message and the content as separate items. The algorithms defined in this document can be found in table-eddsa- algs.  A single signature algorithm is defined which can be used for multiple curves. I-D.irtf-cfrg-eddsa describes the method of encoding the signature value. When using a COSE key for this algorithm the following checks are made: The 'kty' field MUST be present and it MUST be 'OKP'. The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm. If the 'alg' field is present, it MUST match 'EdDSA'. If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature. If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature. </ins> 9. Message Authentication Codes (MACs) provide data authentication and

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
components making calls as part of GNAP, such as the extensions allowing the RS to make calls to the AS defined in {{I-D.ietf-gnap- resource-servers}}. To facilitate this extended use, the sections <del> below are defined in generic terms of the "sender" and "verifier" of the HTTP message.  In the core functions of GNAP, the "sender" is the </del> <ins> below are defined in generic terms of the "signer" and "verifier" of the HTTP message.  In the core functions of GNAP, the "signer" is the </ins> client instance and the "verifier" is the AS or RS, as appropriate. When used for delegation in GNAP, these key binding mechanisms allow

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use
Change:
attribute value and WHIP servers MUST NOT require the usage of any of the extensions. <del> Each protocol extension MUST register an unique "rel" attribute values at IANA starting with the prefix: "urn:ietf:params:whip:". </del> <ins> Each protocol extension MUST register a unique "rel" attribute values at IANA starting with the prefix: "urn:ietf:params:whip:". </ins> For example, taking a potential extension of server to client communication using server sent events as specified in

Discussion:
As per
thank you NAME added new changes per your feedback
PATCH request may be received out of order, how do we handle that? ICE candidate, ICE restart reversed order: ICE candidate with old ufrag should be discarded ICE restart, ICE candidate reversed order: Should ICE candidate trigger ICE restart anyway? Agreed solution: use Etag for requests/responses
Change:
use each ticket no more than once, with more recent tickets being used first. <del> Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection, and only if the client provides the same SNI value as in the original connection, as described in Section 3 of RFC6066. </del> <ins> Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the ticket was established: The KDF hash algorithm associated with the cipher suite The SNI value (if any), as described in Section 3 of </ins> Note: Although the resumption master secret depends on the client's second flight, servers which do not request client authentication MAY

Discussion:
Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment.
NAME ping? It would be good to get some resolution in this space, as it's somewhat relevant to URL
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are.
NAME is there a path forward for this (e.g., does it need to go to the list)?
NAME I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another. What say we land this without those pieces and then when we we will know what to do
SGTM. Do you need me to adjust the patch?
Nah, I'll do it.
These actually just seem to make the SNI requirements clearer but no sharper, so merging.
The Early Data Indication section contains this sentence: The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK. This implies to me that you can only do 0-RTT where the PSK was established via an earlier connection. In external PSK this is not the case. I don't think this interpretation was the intention.
This is stale text from before we allowed 0-RTT with external PSK, IIRC.
Zero-RTT Data says: But 4.6.1. New Session Ticket Message says: For consistency, I would like to have the latter in Section 2.2 with the same style. Moreover, I would like to know where this differences of requirements come from.
I think 4.2.10 may be more appropriate than 2.2, as it is closer to where the server is doing the relevant processing.
Now 4.2.10 has clear requirements. So, why don't we remove the same requirement from 2.3? additional information MUST be provisioned to both parties:
Change:
Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size.  There is a need for the ability to have the basic security services defined for this data <del> format.  This document specifies processing for signatures, message authentication codes, and encryption using CBOR.  This document also specifies a representation for cryptographic keys using CBOR. </del> <ins> format.  This document defines the CBOR Object Signing and Encyption (COSE) specification.  This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization.  This specifiction additionally specifies how to representat cryptographic keys using CBOR. </ins> Contributing to this document

Discussion:
We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure. I was a bit more complete than the original suggestion but it is probably simpler to get right that way.
It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later. It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information. I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.
Did not correctly read the spec.
Change:
In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket. <ins> An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert. </ins> 4. IANA is requested to assign a new value from the TLS ExtensionType

Discussion:
This is to address a comment by Michael StJohns on the mailing list. To quote:
Change:
A sending implementation MUST be able to support the following configurations: <del> multiplex all media and data on a single 5-tuple (fully bundled) </del> <ins> Multiplex all media and data on a single 5-tuple (fully bundled) </ins> <del> send each media stream on its own 5-tuple and data on its own </del> <ins> Send each media stream on its own 5-tuple and data on its own </ins> 5-tuple (fully unbundled) It MAY choose to support other configurations, such as bundling each

Discussion:
Note that this differs from what was said at the IETF meeting - after considering, I didn't see a reason to recommend ICE restart. The text does not contain MUST or SHOULD. This is implementation advice.
FWIW ... This looks good to me
Per Martin, need to be explicit that switching to DSCP 0 needs doing for the media type as a whole, because the DSCP codepoints in a transport are chosen for compatibility on classes (AF4x for instance).
From Magnus Westerlund in IETF LC: Section 4.2: The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. As raised on the TSVWG and RTCWEB mailing list recently in regards to draft-ietf-tsvwg-rtcweb-qos there have been a recent study (URL) showing that non zero DSCP values resulted in consistent failures in 10-13% of the tested paths. So I think it worth considering if this text needs to be sharpen, and possibly actually point to a solution that needs to be specified?
Resolution in WG in Berlin: "We will treat DSCP-induced path failure parallel with other types of path failure, and resolve it by using an ICE restart". Note: There is a problem with multiple DSCP codepoints on a single transport, where one might be blocked and another might get through. In this case, the ICE probes (using one DSCP code point) may succeed while others fail. This is complex, and should be warned about - likely mode of solution is ICE restart with DSCP markings turned off, but detection requires watching the multiple DSCP-codepoint-using channels for differential failures. See minutes for details.
From Martin Thomson: URL - I know what you mean, of course. Presumably if DSCP 0 passes, but probes with DSCP N fails, only traffic that was intended to be sent with DSCP N would be sent with DSCP 0. If DSCP M succeeds, then you could continue to use that; your text implies otherwise. You might like to point out that switching DSCP marking mid-flow can have negative effects on things like congestion controllers and loss recovery.
Change:
can be applied to a sequence of zero or more arguments, producing a result. <ins> A function extension MUST be defined such that its evaluation is side-effect free, i.e., all possible orders of evaluation and choices of short-circuiting or full evaluation of an expression containing it must lead to the same result.  (Note that memoization or logging are not side effects in this sense as they are visible at the implementation level only -- they do not influence the result of the evaluation.) </ins> A function argument is a "filter-path" or a "comparable". According to filter-selector, a "function-expression" is valid as a

Discussion:
clarify that filter expressions are side-effect free and therefore, short-circuiting does not make a difference
In C# (and probably other C-style languages), there are two variants for these operators. and are simple boolean logic. They evaluate all of their operands always (left to right). and are "short-circuit" logic. Their operands are evaluated left to right, and as soon as an outcome is known, it stops evaluating. For example, in , the is never evaluated because returns false so the evaluator knows the entire expression will be false. This becomes important for C# as the operands may be methods which have side effects. If I am trying to parse a , then use the I parsed, I can do that all in one statement: (assume returns a ) In this case, never gets called, which means that no log entry is made. But if I use instead will always be called and a log entry will always be created. ( will be the default (0), but it will still be called.) I'm not sure whether we care about such side effects in JSON Path (I'm leaning towards probably not), but it seems necessary to raise the issue. I expect that if we don't care about side effects, this comes down to an optimization strategy and implementor's choice.
This may become more important if certain function extensions end up having side effects. Perhaps we should say implementations MAY short circuit evaluation. Then it's up to users and function extensions to cope.
Actually, it would already become important as soon as we have exception-like semantics on subexpressions. I'd prefer not to have them.
2023-01-10 Interim: Add text that explicitly excludes side effects that affect the evaluation of JSONpath (e.g., beyond memoization or logging), but makes clear that short-circuiting is a valid implementation strategy; functions need to be pure functions.
Change:
3.5.8. <del> The list selector allows combining member names, array indices, and slices in a single selector. Note: The list selector was called "union selector" in JSONPath-orig, as it was intended to solve use cases addressed by the union selector in XPath.  However, the term "union" has the connotation of a set operation that involves merging input sets while avoiding duplicates, so the concept was renamed into "list selector". </del> 3.5.8.1. <del> The list selector is syntactically related to the "index-selector" and the "slice-selector".  It contains two or more entries, separated by commas. 3.5.8.2. A list selector selects the nodes that are selected by at least one of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one of the selector entries is kept as many times in the node list. To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem- overview. 3.5.9. 3.5.9.1. </del> The filter selector has the form "[?<expr>]".  It works via iterating over structured values, i.e. arrays and objects.

Discussion:
To do: [x] Consider reorganising selectors in section 3.3 to match the order of the document [x] Consider reorganising table 1 to match the order of the document Fixes URL
Reorganised selectors in section 3.3 to match the order of the document. Did not reorganise table 1 as it flows better as is.
Filter selectors should come before list selectors to avoid a forward reference. The following comment should be deleted: Also, as noted by NAME at today's interim WG meeting, we should factor out a separate production to avoid repeating here: and here: Possible names for this production: or .
I think we proposed something like ... and here: thanks.
(And once we are don't with this issue, we can reorder table 1. Not quite sure if we want to do this entirely in section order; let's see how that turns out first.)
Change:
This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An comprises a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated <del> KEM shared secret (or "enc"); and the HPKE-protected binary HTTP </del> <ins> KEM shared secret (or "enc"); and an HPKE-protected binary HTTP </ins> request message. An is shown in fig-enc-request. request describes the process for constructing and processing an . <del> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del> <ins> That is, an comprises a Key Identifier, HPKE KEM ID, HPKE KDF ID, HPKE AEAD ID, Encapsulated KEM Shared Secret, and HPKE-Protected Request.  The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in key-config.  The Encapsulated KEM Shared Secret is the output of the "Encap()" function for the KEM, which is "Nenc" bytes in length, as defined in HPKE. </ins> 4.2.

Discussion:
We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...
Change:
There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes <del> Unencrypted Resolvers on non-public IP addresses whose identity cannot be confirmed using TLS certificates. </del> <ins> Unencrypted Resolvers on non-public IP addresses such as those defined in RFC1918 whose identity cannot be confirmed using TLS certificates. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver

Discussion:
The document was inconsistent, with the authenticated section saying same IP addresses MAY use opportunistic, but the opportunistic section saying the same IP address exception was for private IP addresses only.
Forgot to mention this is to address issue
From Eliot Lear: Can you explain the following statement? and that IP address is a private address (such as those defined in [RFC1918] I ask because it appears that you are using private addresses as some sort of security property. I recommend against that, not least of which is that end systems that are likely to deploy this stuff will have a wide ranging mishmosh of addressing plans, and of course, private network addresses don’t really have any positive security properties to speak of. The only aspect I can see is that one really has to be quite careful of including private network addresses in certificates. Of course, public trust anchors won’t allow it, but even private ones will have some difficulty. Your average bank might have multiple overlapping zones of trust - it’s a pretty hairy scene.
The intent of that section is to say that "if you were going to send this local IP address unencrypted traffic anyway, using encryption to that same IP address is a net improvement to the threat model." It certainly was not meant to imply that private addresses could be verified via the TLS cert SAN mechanism used for public addresses. I can try to rephrase this section to be more accurate. Please comment again if I missed the point.
In reviewing the opportunistic section, I see what you mean Eliot. The need to use "private IP" as a feature is not necessary since same-IP opportunistic discovery is permitted whether the address is private or not. However, the draft conflicted on that point. I have a PR to remove the local IP address as a decision branch and make the draft consistent.
With the PR merged, I am closing this issue.
Change:
IANA is requested to create the following two entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(0xff08), with "TLS 1.3" column values being </del> <ins> encrypted_client_hello(0xfe08), with "TLS 1.3" column values being </ins> set to "CH, EE", and "Recommended" column being set to "Yes". <del> outer_extensions(0xff04), with the "TLS 1.3" column values being </del> <ins> outer_extensions(0xfd00), with the "TLS 1.3" column values being </ins> set to "", and "Recommended" column being set to "Yes". 11.2.

Discussion:
cc NAME NAME
Yeah, that's what I figured. I doubt we'll need more than 8, but we can pick a different range if that works?
Yeah, this works for me. I don't see any reason why we should keep the code points dense.
Note to self. Let's pick a set and range that works.
Change:
The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it.  The final node does not process the RPI, the node ignores the RPI.  Further details about <del> this are mentioned in I-D.thubert-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </del> <ins> this are mentioned in I-D.ietf-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </ins> The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression RFC6437.

Discussion:
RPL was missing a good definition of a LEAF. this clarifies.
updated the deprecated ref to rul draft
Change:
packets larger than the smallest allowed maximum packet size of 1200 bytes. <ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. 14.1. </ins> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)