jiebi/CodeConvo huggingface dataset:
Change:
Shortand notations are also provided that correspond to the shorthand forms of the child segment. <del> The "descendant-wildcard-shorthand" is shorthand for "..[*]". </del> <ins> "..*", the "descendant-segment" directly built from a "wildcard- selector", is shorthand for "..[*]". </ins> <del> A "descendant-member-name-shorthand" of the form "..<member-name>" is shorthand for "..['<member-name>']". </del> <ins> "..<member-name>", a "descendant-segment" built from a "member-name- shorthand", is shorthand for "..['<member-name>']".  As with the similar shorthand of a "child-segment", note that this can only be used with member names that are composed of certain characters, as specified in the ABNF rule "member-name-shorthand". </ins> Note that ".." on its own is not a valid segment.

Discussion:
Can you explain how the test scripts work and how to interpret the output, please?
I haven't done the work to make this a real CI script. You clone the JPC to a directory parallel to where you cloned the I-D repo. kdrfc draft-ietf-jsonpath-URL sh URL ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-URL > scripts/test-URL 2>&1 Compare the output with the checked-in output. (The output contains all parse failures, including the intentional ones. The word FAIL tells you about unexpected output.) An output that says "successfully completed" at the end has done exactly that.
~JPC?~ oh... json path comparison
Is this something that should be in the same repo as the spec? Seems like it should be with a test suite. Or do we plan to remove it before publication?
Indeed -- URL mentioned json-path-comparison (which I call JPC) and jsonpath-compliance-test-suite (which I call CTS). Of course I'd love to get more test data...
This repo contains everything that is needed to work on the spec document. Testing the ABNF in the spec document is a typical case for including tests with the code. It's testing the document. The information in there can possibly be used for building test suites, but I'd rather use the original data in JPC and CTS (which already is a test suite). The test data specifically collected (test-URL) could indeed be used for further testing, but it probably makes more sense to include sample documents and sample query results with that (which were not needed to test just the ABNF). We publish the spec (as an RFC). The repo that creates the spec is public, but not "published" in the stricter sense.
Two objectives: (1) aesthetic cleanup, e.g.: URL (2) more tests, e.g., to be built from query corpora we can find
Looks plausible. I haven't reviewed or run the Ruby code.
Change:
Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format. <del> 10. </del> <ins> 9. </ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct.

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
intermediaries follow the requirements in WEBTRANSPORT-H3 to use native QUIC datagrams. <del> 7. </del> <ins> 6. </ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.
Change:
Same meaning as the corresponding server field defined in <ins> If this field is present with the value "true", then the server MUST NOT create a new account if one does not already exist.  This allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). </ins> The server MUST ignore any values provided in the "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future,

Discussion:
Depends on
This allows us to address the account URL recovery use case in without having special handling for empty payloads.
Change:
fleet.  Note that the version in the Chosen Version field is not necessarily included in this list, because the server operator could be in the process of removing support for this version.  For <del> the same reason, this field MAY be empty. </del> <ins> the same reason, the Other Versions field MAY be empty. </ins> Clients and servers MAY both include versions following the pattern 0x?a?a?a?a in their Other Versions list.  Those versions are reserved

Discussion:
The draft says: Server-Sent Other Versions: When sent by a server, the Other Versions field lists all the Fully-Deployed Versions of this server deployment, see Section 2. Note that the version in the Chosen Version field is not necessarily included in this list, because the server operator could be in the process of removing support for this version. For the same reason, this field MAY be empty. But the syntax is: What does the draft exactly mean by "this field MAY be empty"?
The "Other Versions" field contains a list of versions, whose length can be zero. That text exists to remind people that the list of Fully-Deployed Versions can be empty, and that shouldn't cause handshake failures.
The text is far from clear, because the sentence mixes references to "Other Versions" and "Chosen version". Stating "For the same reason, the Other Versions field MAY be empty" would remove the ambiguity.
Thanks for clarifying, I've written that up as .
Change:
Abstract Web bundles provide a way to bundle up groups of HTTP responses, with <del> the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level resources, provide random access to their component exchanges, and efficiently store 8-bit resources. </del> <ins> the request URLs that produced them, to transmit or store together. They can include multiple top-level resources, provide random access to their component exchanges, and efficiently store 8-bit resources. </ins> 1.

Discussion:
This PR removes content negotiation from the spec. It is more efficient to use content negotiation on the server to select which bundle to send, rather than including several variants in the bundle and having that negotiation happen on the client's side. Issue: URL Adapted from URL
Now that the working group has adopted the document, we actually need them to approve significant changes like this one, not me. We can check on this one during the IETF meeting .
Moved from NAME URL It's more efficient to use content negotiation to select which bundle to serve, rather than including several variants of a resource inside a bundle. Even most use cases around re-sharing bundles while offline can get away with including a single least-common-denominator resource. I only know of the case of translations that concretely need several variants of the same resource. Can we simplify the design by omitting content negotiation? We'd lose some fidelity in representing HTTP, but that might be acceptable.
I"m fine to remove the variants support from the bundle format, however, I'm wondering how removing the variants support impacts on the chromium's implementation. We should align somehow. NAME NAME Do you know any use case of variants? Can we remove variants support from the bundle format without any impacts on the chromium?
Chromium supports variants in Navigation to Web Bundles (URL), but not in Subresource loading with Web Bundles. Since Navigation to Web Bundles hasn't shipped yet, I think it's fine to remove it from Chromium.
If we remove the content negotiation, it may become difficult to support new data formats like WebP in future. But removing it from the bundle format now and re-thinking when it will be more important sounds acceptable.
The idea here is that you would negotiate for the whole bundle, not for resources within the bundle. I think this could permit upgrade to new image formats over time, without shipping all the different options redundantly to the client.
I think we can close this issue. Content negotiation was already dropped.
Thanks for making a PR! Per the discussion URL, the chromium side is okay to remove content negotiation. We probably have to change parser's behavior by checking a bundle's version. That should not be a significant issue for us. We might want to wait for NAME 's approval before merge.
Change:
values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. <ins> Regardless of the Ta value chosen for each ICE agent, the combination of all transactions from all ICE agents (if a given implementation runs several concurrent ICE agents) MUST NOT be sent more often than once every 5ms (as though there were one global Ta value for pacing all ICE agents). This mechanism of a global minimum pacing interval of 5ms is not generally applicable to transport protocols, but is applicable to ICE based on the following reasoning. Start with the following rules which would be generally applicable to transport protocols: Let MaxBytes be the maximum number of bytes allowed to be outstanding in the network at start-up, which SHOULD be 14600 bytes per RFC 6928. Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT is known and 500ms otherwise.  This is based on the RTO for STUN messages from RFC 5389 and the the TCP initial RTO, which is 1 sec in RFC 6298. Let MinPacing be the minimum pacing interval between transactions, which SHOULD be 5ms. Observe that ICE agents typically do not know the RTT for ICE transactions (connectivity checks in particular), meaning that HTO will almost always be 500ms. Observe that a MinPacing of 5ms and HTO of 500ms gives at most 100 packets/HTO, which for a typical ICE check of less than 120 bytes means a maximum of 12000 outstanding bytes in the network, which is less than the maximum expressed by rule 1. Thus, for ICE, the rule set reduces down to just the MinPacing rule, which is equivalant to having a global Ta value. </ins> NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values.

Discussion:
Annex B.1 also contain some text regarding the rate. E.g. "The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media starts flowing." I guess we should discuss whether: 1) We need to remove/modify that text 2) Whether B.1 is the place where we should talk about the global rate limit.
I'll own this issue because I'm driving discussion on the list around the transport guys' proposal for "MaxPackets+HTO+pacing".
Hopefully fixed by URL
Change:
CAs using ACME to allow clients to agree to terms of service should keep in mind that ACME clients can automate this agreement, possibly <del> not involving a human user.  If a CA wishes to have stronger evidence of user consent, it may present an out-of-band requirement or challenge to require human involvement. </del> <ins> not involving a human user. </ins> 11.

Discussion:
The OOB challenge was added to accommodate non-ACME CAs building ACME integrations. Since then two non-ACME CAs have implemented ACME integrations using the external account binding feature but not implementing OOB challenges. Since the target demographic has not implemented this feature and has also not presented a use-case requiring it there seems to be no strong reasons to keep it in-spec.
NAME If you could update this to remove the OOB challenge from the , I'll go ahead and merge
NAME Good catch - thanks! Addressed in 0753c73.
Change:
Initial contents: <del> These ciphersuites map to HPKE primitives and TLS signature schemes </del> <ins> All of these ciphersuites use HMAC RFC2104 as their MAC function, with different hashes per ciphersuite.  The mapping of ciphersuites to HPKE primitives, HMAC hash functions, and TLS signature schemes is </ins> as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for the MLS transcript hash is the one referenced in

Discussion:
that MLSPlaintext does not currently authenticate the sender's membership on the group, and as a result, some important attacks arise. Discussion on the list indicated that adding a MAC with a key derived from the key schedule would provide this authentication. This PR implements that suggestion.
Lgtm. Rebase and I'll properly approve.
Generally not a fan of rebasing, but here you go.
From NAME ... This would be a useful terminology to describe a client which shares its cryptographic material across multiple device. To be discussed ?
Done in draft-06 Yeah, I like Option 2 here. I like that it avoids growing packet size. One caveat though: I'd go for the MAC(...) version rather than the confirmationkey. For starters thing including confirmationkey doesnt authenticate the contents of the packet. But even if it did, signatures aren't meant to hide the contents of what was signed. (Amend you favorite sig scheme to tack on the message at the end a signature and you've still got a secure signature scheme. But clearly not a message hiding one.) That means that AFAIK neither ECDSA nor EdDSA etc. were designed or analyzed for such a property. So this would amount to a very non-standard use of a signature schemes by MLS. Not saying it doesn't work for the particular sig schemes in our ciphersuite. But its def. not how signatures are "meant" to be used. But that leaves Option 2 with, say, including tag = MAC(confkey, conftranshash MLSPlaintext.content) into whats being signed which I like and think gets the job done. Both conf* values are taken from the current epoch. By MLSPlaintext.content I mean whats now called MLSPlaintextTBS. NAME For Proopsals I think this works. Is that about what you had in mind for commits too? Joël On 18/08/2020 17:26, Richard Barnes wrote: >
Change:
zone.  Authoritative Servers are expected to return all available referral glue records in a referral response.  If message size constraints prevent the inclusion of all in-domain referral glue <del> records over UDP transport, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use TCP to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </del> <ins> records, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use another transport to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </ins> 1.

Discussion:
and talk more generically about message size constraints regardless of transport. For
As currently written the document only talks about setting TC=1 over UDP. This sort of implies that UDP is the only possible transport where TC flag has meaning. We don't talk about setting TC over TCP because the assumption is that TCP always has enough room for all glue or whatever. But this doesn't account for two possibilities 1) a future transport that is limited in space 2) some kind of ridiculous zone configuration with so many NS and glue records that they won't even fit in a single DNS-over-TCP message. Would it be better to just say "set TC=1 if glue doesn't fit" and not bring UDP or TCP into the requirements language?
I like the idea of that, but I think simultaneous possession and ingestion of cake is also possible -- make the general, transport-agnostic point but also give the UDP/TCP fallback as an example that is known to be common at the time of writing. Joe
I prefer mentioning UDP and TCP and to say clearly never set it for TCP. I wouldn't consider "insanely weird" TCP that requires TC=1
would or wouldn't?
was merged so closing this for now
Change:
fields of the payload of the "encrypted_client_hello" extension.  The last parameter, "outer_hello", is computed by serializing ClientHelloOuter with the "encrypted_client_hello" extension removed. <ins> Note this does not include the four-byte header included in the Handshake structure. </ins> Note the decompression process in encoding-inner forbids "encrypted_client_hello" in OuterExtensions.  This ensures the

Discussion:
Clarifies that serialization of this structure doesn't include the message type and length. We do the same thing for the serialization of EncodedClientHelloInner, but this makes it explicit in case it's not clear from context.
Change:
4.1.1. TLS cryptographic negotiation proceeds by the client offering the <del> following four sets of options in its ClientHello. </del> <ins> following four sets of options in its ClientHello: </ins> A list of cipher suites which indicates the AEAD cipher/HKDF hash <del> pairs which the client supports </del> <ins> pairs which the client supports. </ins> A "supported_group" (negotiated-groups) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (key-share) extension which contains (EC)DHE shares for some or <del> all of these groups </del> <ins> all of these groups. </ins> A "signature_algorithms" (signature-algorithms) extension which indicates the signature algorithms which the client can accept.

Discussion:
I took this bit out of the 1st paragraph: -If any of these parameters has no overlap between the -client and server parameters, then the handshake -will fail. and moved it to the last para in the section because it doesn't say what alert value is to be returned, there's not something similar in the following paragraph that describes the PSK failure case, and finally the full failure text is included in the final paragraph. Basically, I just move the failure case to the final paragraph. An alternate would be to copy the failure to the PSK paragraph and include the which alert to return in the non-PSK para.
Change:
The security and privacy considerations outlined in Section 5 of RFC7807 apply in full. <del> 5. </del> <ins> 7. </ins> TODO.

Discussion:
Note that this PR sits on top of
CoAP Response Codes are an optional feature and should be discussed in a separate section. Rationale for the feature The CoAP response-code is already carried by the CoAP header, so it doesn't make sense adding it to the PD payload that goes from Server to Client. It does however make sense for a Client that is about to ingest the received PD into a log pipeline to "enrich" it with ancillary Information from the underlying CoAP transaction. In this context, response-code is probably the most basic attribute that one wants to carry over as it is also commonly used as a high-level partition key for log visualisation.
addressed by
We should provide a default set of ready-to-use PD types associated with the existing CoAP status codes, intended for carrying (and enriching) the associated status code semantics. The (rough) plan is to define an “about:coap” namespace with one PD type for each registered . An application could use such PDs without the need to register anything. Just pick the "right" type and populate the relevant fields, job done. As a nice side-effect, this would allow exercising the registration procedure, including the definition of the PD type's registry structure and providing a first set of registrations.
Change:
A sender can make exceptions for probe packets so that their loss detection is independent and does not unduly cause the congestion controller to reduce its sending rate.  An endpoint might set a <del> separate timer when a PATH_CHALLENGE is sent, which is cancelled when </del> <ins> separate timer when a PATH_CHALLENGE is sent, which is cancelled if </ins> the corresponding PATH_RESPONSE is received.  If the timer fires before the PATH_RESPONSE is received, the endpoint might send a new PATH_CHALLENGE, and restart the timer for a longer period of time. <ins> This timer SHOULD be set as described in Section 5.3 of QUIC-RECOVERY and MUST NOT be more aggressive. </ins> 9.5.

Discussion:
Section 9.4 of draft-ietf-quic-transport: An endpoint might set a separate timer when a PATHCHALLENGE is sent, which is cancelled when the corresponding PATHRESPONSE is received. If the timer fires before the PATHRESPONSE is received, the endpoint might send a new PATHCHALLENGE, and restart the timer for a longer period of time. GF: Possibly so, but what value has this timeout? To avoid potential congestion collapse, I think this needs to be conservative enough to deal with paths with significant RTT variance, or where there is a change of base RTT. 1 sec, then 3 seconds, and then exponentially backed-off would be expected for TCP SYNs, and I suggest could be appropriate.
The suggestion is to move some of this text to recovery(ie: Handshakes and New Paths) and reference that text from transport.
As Jana pointed out, this specifies a separate timer, which fits fine with the model that there's one timer per path.
This can be simpler -- just add the new sentence. I've made suggestions.
Change:
with a management URL and a response-subject in the form of an opaque identifier. <del> In this example, the AS is returning only a pair of response-subject as both an email address and an opaque identifier. </del> <ins> In this example, the AS is returning set of response-subject, simultaneously as an opaque identifier, an email address, and a decentralized identifier (DID). </ins> 3.1.

Discussion:
To align with secevent draft 8 which added DIDs
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 6ded21ad57eed6fd25df2ca4fb77dcf186c93209 :mag: Inspect the deploy log: :sunglasses: Browse the preview: