jiebi/CodeConvo huggingface dataset:
Change:
Specific processing MUST also be applied for the following attribute lines: <del> If the "m=" proto value indicates use of RTP, as described in </del> <ins> If the "m=" <proto> value indicates use of RTP, as described in </ins> sec.profile-names above, the following attribute lines MUST be processed: <del> Otherwise, if the "m=" proto value indicates use of SCTP, the </del> <ins> Otherwise, if the "m=" <proto> value indicates use of SCTP, the </ins> following attribute lines MUST be processed: Other attributes that are not relevant to JSEP may also be present,

Discussion:
The following changes have been made: changed to "set to zero" from "set to 0", removed comment. formatted media-field subfields consistently, removed comment.

fmt value / "fmt" value Justin: Would we also do media, port, and proto? This one needs more discusison.
RFC 4566 (SDP) was inconsistent in the formatting of fmt (, "fmt"), proto ("proto", ), and port (port, ). For the most part, media was just formatted media. RFC 8866 (SDP), which obsoletes RFC 4566, consistently formats these "m=" line subfields as , , , and . This document uses the following formats: fmt (3 instances) vs (2 instances) proto (7 instances) vs (5 instances) port (31) vs (0 instances) -- most are not referring specifically to the subfield, though I suggest using angle brackets (but not formatting -- I was just working around GitHub's markdown with that) for these terms when discussing "m=" line subfields.
SGTM, let's align with 8866 usage when an instance of these words refers specifically to a m= line subfield.
set to zero / set to 0 >(May we use the latter, because of '"dummy" port value of 9' in Sections 5.2.1 and 5.3.1?) Justin: What's the IETF style guide say on this sort of thing? 'zero' looks more natural to me, and matches RFC 3264's usage of 'zero'.
From our style guide: "In general text, we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits. However, if a value is followed by a unit of measure (e.g., 8 bytes, 3 octets), it should be in digit form regardless of value." There is one instance of "set to 0" in this document vs four instances of "set to zero". I can change that one instance to match the other four.
LGTM
Change:
node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. <del> The HPKECiphertext values are computed according to the Encrypt function defined in I-D.barnes-cfrg-hpke. </del> <ins> The HPKECiphertext values are computed as where "node_public_key" is the public key of the node that the path secret is being encrypted for, and the functions "SetupBaseI" and "Seal" are defined according to I-D.barnes-cfrg-hpke. </ins> Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted

Discussion:
Here's the Weekly Digest for : This week, 8 issues were created. Of these, 4 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by The issue most discussed this week has been: :speaker: , by It received 9 comments. This week, no pull requests has been proposed by the users. This week, 4 users have contributed to this repository. They are , , , and . This week, no user has starred this repository. This week, there have been 4 commits in the repository. These are: :hammerandwrench: Merge pull request from rozbb/mlsplaintext-signature Multiple clarifications around Framing by :hammerandwrench: Merge pull request from rozbb/hpke-encrypt Clarify how HPKE ciphertexts are computed by :hammerandwrench: by :hammerand_wrench: by # RELEASES This week, no releases were published. That's all for this week, please watch :eyes: and star :star: to receive next weekly updates. :smiley:
Change:
the end of the body. Verify that key authorization provided by the HTTP server matches <del> the key authorization provided by the client in its response to the challenge. </del> <ins> the key authorization stored by the server. </ins> The server SHOULD follow redirects when dereferencing the URL.

Discussion:
Respond with {} instead of providing keyAuthorization Remove "keyAuthorization" from the challenge object returned by the server. Fixes a potential misguide for clients that enabels a MitM attack. Keep the storing of the keyAuthorization on response to retain the same behavior if an account key roll-over happens before the challenge is validated
I like this change in theory, but it's substantive enough that I'd like to give the mailing list a couple more pokes to see if anyone has further thoughts on it before we land it.
This is not an editorial change, and I think it would require pushing back further on last-call timing. Please bring this up and discuss on the mailing list; WG consensus will be required.
This was brought up on the list Dec 27th and only positive responses were received.
https://ietf-wg-URL From the spec This is not consistent with the example: Which is posting to . I would expect the example to show has . Also, there is no other mention of present in the example payload. Is this a mistake?
The example is correct. The URL for the challenge is , as shown in the response body above the example you cite: (Note the at the end that distinguishes the challenge from the authz URL ) As for the field, it looks like NAME fixed this in
thanks
This PR looks good to me. I think the proposed change makes sense and removes a potential error without sacrificing anything functionality wise. NAME NAME Can you give this a review as well?
Change:
The challenges that the client can fulfill in order to prove possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array <del> entry is a dictionary with parameters required to validate the </del> <ins> entry is an object with parameters required to validate the </ins> challenge.  A client should attempt to fulfill at most one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.

Discussion:
Follow-up to , catches a few more references I initially missed.
I think 'field name' makes more sense... but I'm not really wed to either.
Change:
Verify that the value of "leaf_node.encryption_key" is different from the value of the "init_key" field. <del> 11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g., joining-via-welcome-message).  The "external_key_id" extension allows applications to add an explicit, application-defined identifier to a KeyPackage. </del> 12. A group is always created with a single member, the "creator".  The

Discussion:
At first I was going to make an extension for both KeyPackages and LeafNodes. But I was thinking and couldn't come up with a reason for KeyPackages to need this extension, so did just LeafNode.
Interim 2022-05-26: Agreement to merge is getting used a lot, so maybe or ? NAME to change to
What's the use case for this?
Mentioned at the last interim, but the use-case for this feature is either: giving applications an easier way to lookup the private key corresponding to their LeafNode giving applications a place to put client UUIDs
Change:
Preference, which is an Enumeration with five possible values: Prohibit, Avoid, Ignore, Prefer, or Require.  Each of these denotes a level of preference of a given property during protocol <del> selection.  (See selection-props.)  The Preference type is used only on Preconnections, and only for Selection Properties. </del> <ins> selection.  (See also selection-props.)  The Preference type is used only on Preconnections, and only for Selection Properties. </ins> 3.3.

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.
Change:
[sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion. <ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below: This 64-bit value is used in the ACK message as well as in the "record_sequence_number" input to the AEAD function. </ins> The entire header value shown above is used as it appears on the wire as the additional data value for the AEAD function.  Note that this design is different from the additional data calculation for DTLS 1.2

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.
Change:
Safely Replayable: when this is true, this means that the Message can be used by mechanisms that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP <del> Fast Open. </del> <ins> Fast Open.  Also, protocols that do not protect against duplicated messages, such as UDP, can only be used with Messages that are Safely Replayable. </ins> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. Corruption Protection Length: when this is set to any value other <del> than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </del> <ins> than "Full Coverage", it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). Reliable Data Transfer (Message): When true, the property specifies that the Message must be reliably transmitted.  When false, and if unreliable transmission is supported by the underlying protocol, then the Message should be unreliably transmitted.  If the underlying protocol does not support unreliable transmission, the Message should be reliably transmitted. Message Capacity Profile Override: When true, this expresses a wish to override the Generic Connection Property "Capacity Profile" for this Message.  Depending on the value, this can, for example, be implemented by changing the DSCP value of the associated packet (note that the he guidelines in Section 6 of RFC7657 apply; e.g., the DSCP value should not be changed for different packets within a reliable transport protocol session or DCCP connection). No Fragmentation: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface).  Messages larger than this size generate an error.  Setting this avoids transport- layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.

Discussion:
I also added a link to NEATPy in the overview of implementations, and inserted a missing word in interface (a missing "without", must have been a nit)
It might be worth to better align the sections on Message Properties in the API and Implementation draft. Note that e.g. "Final" has more implementation details in the API draft than in the implementation draft.
Change:
registration of endpoints, as a query parameter in lookups, or be expressed as a target attribute, <del> validity requirements if any, </del> <ins> syntax and validity requirements if any, </ins> a description,

Discussion:
It appears I've missed some of Alexey's remarks responding to the changes made after his initial review (, 2019-11-20). This contains fixes for the points he still wanted changed / suggested after my original response to his review.
Change:
which do not depend on the (possibly updated) KeyShareClientHello, i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello <del> messages.  Moreover, ClientESNIInner.nonce and ClientESNIInner.realSNI MUST not change across ClientHello messages. Informally, the values of all unencrypted extension information, as well as the inner extension plaintext, must be consistent between the first and second ClientHello messages. </del> <ins> messages.  Moreover, ClientESNIInner MUST not change across ClientHello messages.  Informally, the values of all unencrypted extension information, as well as the inner extension plaintext, must be consistent between the first and second ClientHello messages. </ins> 5.1.3.

Discussion:
Since the client's ESNI key share doesn't change across CHs in response to a HRR, the same AEAD IV would be used to encrypt/decrypt two different messages. This is an attempt to fix that, while also specifying the server-side HRR behavior. (Basically, check that the ESNI contents have not changed.)
Nice catch, Would it make more sense to instead use the KeyShare as a salt in the HKDF?
Or you could include the handshake transcript up to, but not including, the ClientHello. That is the empty string before HRR< but something else after.
That is a little iffy with cookie-only HelloRetryRequests. Those don't change the ClientHello key shares list, so the client would derive the same key + nonce pair. The client would also use the same plaintext so it's fine, but it seems an unnecessarily fragility.
Agreed. I think I prefer the "new DH" version.
Thank you for the changes! LGTM.
Change:
9. <del> TBD. </del> <ins> An improperly configured or malicious data sender could cause a data receiver to acknowledge more frequently than its available resources permits.  However, there are two limits that make such an attack largely inconsequential.  First, the acknowledgement rate is bounded by the rate at which data is received.  Second, ACK_FREQUENCY and IMMEDIATE_ACK frames can only request an increase in the acknowledgment rate, but cannot force it. In general, with this extension, a sender cannot force a receiver to acknowledge more frequently than the receiver considers safe based on its resource constraints. </ins> 10.

Discussion:
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?
I believe a data sender can attack a data receiver's resources by using ack-frequency to make the receiver ACK more frequently than it can cope with. For instance, a data sender could set Ack-Eliciting Threshold low, then send small packets at high rate. Multiple data senders (eg. a bot net) could adopt this strategy to force a server to spend a large proportion of its resources receiving small packets and sending out QUIC ACKs. So I think the draft ought to say that a QUIC data receiver treats the Ack-Eliciting Threshold as a polite request, and it can ACK less frequently if its resources are limited. Currently §7 of the draft says: This is where I suggest it ought to say SHOULD, and explain why it is not a MUST. Unfortunately, this means a genuine data sender cannot deterministically rely on the receiver complying with an ack-frequency request, e.g. a sender cannot use ack-frequency to reduce the time it has to wait before it deems there must have been a loss. But, I guess a sender that is not being unreasonable will usually be able to rely on the receiver doing as requested. There's probably a similar line of argument to this whole issue for minackdelay.
The client does not know very much about the sensibility of a particular request. e.g. a request trying to force a high ACK rate - or a request reducing the ACK frequency to a very long period - using up cwnd to reach flow-control limits and stall. I think this totally relies on the server requesting sensible values. But that's fine - we could say what is sensible if we wish.
Change:
nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist. <del> A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. </del> 3.5.5.2.1. A singular path by itself in a Boolean context is an existence test

Discussion:
There may be some more shake-out as filter semantics are scattered through the syntax section. We may need to live with this because it makes more sense to talk about semantics in the context of each particular piece of syntax. But let's use the current PR just to use the current node term consistently.
Change:
"https://example.org/captive-portal/api/X54PD" <ins> 3.1.1. The purpose of accessing the Captive Portal API over an HTTPS connection is twofold: first, the encrypted connection protects the integrity and confidentiality of the API exhange from other parties on the local network; and second, it provides the client of the API an opportunity to authenticate the server that is hosting the API. This authentication is aimed at allowing a user to be reasonably confident that the entity providing the Captive Portal API has a valid certificate for the hostname in the URI (such as "example.com").  The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service. Clients performing revocation checking will need some means of accessing revocation information for certificates presented by the API server.  Online Certificate Status Protocol RFC6960 (OCSP) stapling, using the TLS Certificate Status Request extension RFC6066 SHOULD be used.  OCSP stapling allows a client to perform revocation checks without initiating new connections.  To allow for other forms of revocation checking, a captive network could permit connections to OCSP responders or Certificate Revocation Lists (CRLs) that are referenced by certificates provided by the API server. Certificates with missing intermediate certificates that rely on clients validating the certificate chain using the URI specified in the Authority Information Access (AIA) extension RFC5280 SHOULD NOT be used by the Captive Portal API server.  If the certificates do require the use of AIA, the captive network will need to allow client access to the host specified in the URI. If the client is unable to validate the certificate presented by the API server, it MUST NOT proceed with any of the behavior for API interaction described in this document.  The client will proceed to interact with the captive network as if the API capabilities were not present.  It may still be possible for the user to access the network by being redirected to a web portal. </ins> 3.2. The Captive Portal API data structures are specified in JavaScript

Discussion:
Addresses , with the decisions made at the last IETF meeting
Added text based on Martin's suggestions
As David Bird pointed out, we should describe the model we assume for API server authentication. Then we need to describe the requirements on this. An important point here is that CRL or OCSP checking are likely to fail for a captive UE. A recommendation for servers to use OCSP stapling is likely necessary (whitelisting CRL or OCSP servers is probably workable, but OCSP stapling is a far superior solution).
This needs to mention AIA chasing as well. Some client implementations do that (others think that it's a crazy idea, but that's not a debate we need to enter into here).looks good.
Change:
learned through other means, e.g., receiving it in a separate server-reflexive remote candidate. <del> 3.2. </del> <ins> 4.2. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname

Discussion:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM
Change:
Each URI is tagged with whether it is intended to be dereferenced or used as an identifier. <del> Equivalence of literals over CBOR packing could be revisited; literals could gain an identity from all their outgoing trees being identical.  (But that'd need an exception for Null literals).  It might help to explicitly limit these sub-trees. Alternatively, literals in the model could be replaced with this, and be disallowed in the subject position: Literals can have properties in addition to their literal (CBOR) value.  These properties are expressed in key-value pairs very similar to statements about the literal in that the keys are URIs, the values URIs or literals, and keys can occur multiple times. (In serializations like binary, they are expressed exactly the same).  However, unlike statements, these properties of the literal and (transitively) part of the literal's identity, and are always expressed completely in the structured information model. If this model is adopted, literals obtain their identity from being identical in value and all properties in an unordered comparison.  "null" values need to be excluded from literals, as they need to retain the instance-of-their-own semantics. </del> 1.1.4. This subsection illustrates the information model and serialization

Discussion:
Closes: URL In the comments there's the question of whether we need that properties of literals that are literals themselves can have properties again. Right now it does no harm, but no good either; I have no use case that's not completely contrived, and the number of properties we can round-trip through RDF is quite limited anyway.
I think we should pick the information model variation where literals can't have arbitrary outgoing statements, but only properties (that happen to be serialized just like other statements). Allowing nested statements from literals is kinda nice conceptually, but it is hard to explain (as it requires all the "blank node" explanations over again) is impractical in conversions is hard to visualize correctly Realistically, literals can have a type (if they're string-form; for everything else conversion can be guided by tags) or a language (which AIU is also a type these days when considering LTR/RTL). We might also see things like content format (for embedded representations), but if we want to carry them over to RDF, we can't do the literal attributes anyway, and I think we don't need to (because we now also have 's tags for content formats and can thus easily tag things inside CBOR). Are there any arguments we should have in an issue beforehand? Otherwise I'd start a pull request at my next CoRAL session.
While writing this up, I stumbled over which CBOR data model to pick for equivalence. Making literals identical to each other if they are identical in the CBOR generic data model seems the right thing to do (as opposed to going into the extended data model), as it is easier and stable. I think that we (or applications) can still define additional equivalences later on.