jiebi/CodeConvo huggingface dataset:
Change:
further processing for this m= section can be skipped. Provided that is not the case, each m= section in the answer should <del> then generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ </del> <ins> then be generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ </ins> SAVPF".  If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
6.2.8. <del> FullChecksumRecv </del> <ins> fullChecksumRecv </ins> Preference

Discussion:
As discussed at the last interim, but cleaning up the references to use the real property names too.
Yes, because it's just a quote of the minset RFC's name :) can't change that anymore
Works for me. I'm not hugely sold on "end systems" given my recent experience with the word "system" in arch - but it likely is quite OK here.
Change:
Definition: <ins> 3.5. Importance: Extra This event indicates that the estimated Path MTU was updated.  This happens as part of the Path MTU discovery process. </ins> 4. TBD

Discussion:
While DPLPMTUD is optional, there's an about it in QUIC transport. Minimal support for this in qlog would define an event for every increase of the MTU: I don't think we need a separate event for the sending of an MTU probe packet, but we should probably standardize a for this. Suggestion: . Open question: Do we want a separate failure event? Failure would be either the loss of an MTU probe packet, or (for implementations that pay attention to ICMP packets) the receipt of an ICMP Packet Too Big (PTB) message.
I agree it would be useful to have this information in qlog. In terms of design, as always there are several options: 1) have separate events for this (, , , etc.) 2) integrate them into existing events( triggers on and , new field in ) 3) a combination of these approaches (which is what you suggest IIUC) This is imo a good example of where we need clear design guidelines on how to add new information/events to qlog.
Revisiting this after a long time: is problematic, as this would essentially be a copy of the normal event (it is allowed, although not recommended, to just send normal application data as a probe packet). The trigger seems to be the best solution here needs to be a separate event, there's just no way we can reasonably collapse this into an acknowledgment event is what I'm still undecided about. This logically belongs to the regular event, we'd just need a way to attach "oh and by the way, this was a MTU probe packet". In fact, it would be really useful to have it on that event, since the congestion control implications are very different for lost MTU packets (i.e., you wouldn't decrease your cwnd).
I have to disagree with myself here. The sending of the packet might have been triggered by something else, it's just that the stack decided to send a probe packet. I suggest: Add a optional on the and events. Add a event.
Supporting DPLPMTUTD events seems important to cover in the base specs.
Change:
5.2. <del> In order to support message loss, reordering, and message fragmentation, DTLS modifies the TLS 1.3 handshake header: </del> <ins> DTLS uses the same Handshake messages as TLS 1.3.  However, prior to transmission they are converted to DTLSHandshake messages, which contain extra data needed to support message loss, reordering, and message fragmentation. In DTLS 1.3, the message transcript is computed over the original TLS 1.3-style Handshake messages without the message_seq, fragment_offset, and fragment_length values.  Note that this is a change from DTLS 1.2 where those values were included in the transcript. </ins> The first message each side transmits in each association always has message_seq = 0.  Whenever a new message is generated, the

Discussion:
This makes the handshake the same as TLS 1.3 (modulo the version numbers, which are conveniently different.
As discussed at the meeting. NAME PTAL.
This also LGTM. Let's do a brief consensus call before merging.
Change:
NOT be added but the matched Record (if any) is removed from the Target Pack. <ins> The Patch Records MUST be applied in the same sequence they are in the Patch Pack. Implementations MUST reject and generate an error for Patch Packs with invalid Records.  If a Patch Pack is rejected, the state of the Target Pack is not changed, i.e., either all or none of the Patch Records are applied. </ins> For example, the following document could be given as an (i)PATCH payload to change/set values of two SenML Records for the example in intro:

Discussion:
Patch records must match only one Target record Invalid records result in error No Pack state is changed if any invalid records Also: Noted Fetch response must contain each target only once Updated author info
Change:
those privileges to an end-user.  This process is refered to as privilege delegation. <del> protected API (Application Programming Interface) served by a RS </del> <ins> protected API (Application Programming Interface) served by an RS </ins> and that can be accessed by a client, if and only if a valid access token is provided.  Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource. ability given to a subject to perform a given operation on a <del> resource under the control of a RS. </del> <ins> resource under the control of an RS. </ins> person, organization or device.

Discussion:
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fd1d0f88ac7d2a9ad6f43bb6d959a2aa84558f2b https://deploy-preview-179--gnap-core-protocol-editors-URL
One small change needed (marked) but otherwise good!
Change:
ClientHello. Servers MUST NOT send the EarlyData extension.  Negotiating TLS 1.3 <del> serves as acknowledgement that it was processed as described above. </del> <ins> serves as acknowledgment that it was processed as described above. </ins> [[OPEN ISSUE: This is a fairly general mechanism which is possibly overkill in the 1-RTT case, where it would potentially be more

Discussion:
(includes )
I'll let native speakers fix the typos next time xD
Your intuition on how to treat that last one was not wrong, but you need to know the specifics of the terminology to handle it properly. If that weren't a specific term, you'd have been correct, though usage of the word "compatible" there would've been strange. As to hyphenation, tech terminology turns hyphenated words into compound words way faster than natural language evolution. In other words, we tend to make up new words frequently and write them shorter each time. ;)
In my experience, native speakers are usually far from the best :)
Native speakers can muddle through free-form usage easily, so they don't notice how bad things might be to others. Non-native speakers can't intuitively piece together words as easily, and thus follow the rules more, which can be problematic because no verbal language actually follows its own rules fully, especially ones with lots of borrowed words. We all screw up language in different and interesting ways. :p I think a rebase is needed, as the whitespace changes were merged via your other PR. A squash of these commits into one to drop the reverted bits is probably a good idea, while you're at it.
Done, ready for merge... =)
Change:
for nodes in its direct path that are being reset by the corresponding Commit. <del> In the description of the tree as a list of nodes, the "key_package" field for a node MUST be populated if and only if that node is a leaf in the tree. </del> <ins> The client processing a Welcome message will need to have a copy of the group's ratchet tree.  The tree can be provided in the Welcome message, in an extension of type "ratchet_tree".  If it is sent otherwise (e.g., provided by a caching service on the Delivery Service), then the client MUST download the tree before processing the Welcome. </ins> On receiving a Welcome message, a client processes it using the following steps:

Discussion:
A couple of shortcomings to note on this PR: The joiner can't compute their private keys because they're not told where they are in the tree or how big the tree is. The former should be added to and the latter to . This approach assumes that the joiner gets the tree OOB before processing the Welcome, otherwise they can't verify the signature on the Welcome. (Since Welcome presumes they get the credential for the signer from the tree.) We could avoid the latter problem by including a credential for the signer and a "membership proof" comprising the hashes needed to tie that leaf to the tree hash in the Welcome. That could allow participants to remain "passive" (without a full tree, just their private keys) for longer, especially if such a proof could be provided on Commit as well. This might be a good candidate for an extension, though.
Discussion at the 2020-07-14 interim indicated that we should go ahead with this strategy, and just note the requirement that you have to get the tree before you process the Welcome.
I remember we discussed this in the past, but I don't think we ever spec'ed this out fully: Right now the whole tree is part of (which in turn is part of ). This can grow quite big in large groups (~17MB with 100k members with the MTI). The practical limitations are: The TLS representation of the tree is hard to parse efficiently (no skipping and no a priori information of how many nodes are in the tree) Out-of-band transmission (like server assist) is not possible Large messages like that are hard to handle on mobile devices, when they have to be downloaded in the background We should introduce an indirection, like a commit hash of the tree.
Change:
16. <ins> freshness discussed various issues and requirements around freshness of evidence, and summarized three approaches that might be used by different solutions to address them.  This appendix provides more details with examples to help illustrate potential approaches, to inform those creating specific solutions. </ins> The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time, such as the Coordinated

Discussion:
Note that section 10.4 (Freshness.Discussion) already said: So the intro text tries to be consistent with that phrasing. Signed-off-by: Dave Thaler
pushed 7c75ffe to fix the CI
Appendix A needs more introduction text to highlight its value to the reader.
LGTM
Change:
If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second ClientHello message.  Moreover, if this extension is present, a <del> client MUST NOT change the value of TicketRequestContents.count in the second ClientHello message. </del> <ins> client MUST NOT change the value of ClientTicketRequest in the second ClientHello message. </ins> 4.

Discussion:
This is without ticket re-use text. This also includes changes from . The following table outlines the ticket request values for a a client that wants N tickets and always attempts to race a connection across K paths. Did I get this right? Does this make sense? Should we put this in the document directly?
NAME NAME do you think we should include the table in the PR's description in the text? I think its contents are implied from the text, so adding more text is just being verbose. But I could be persuaded otherwise.
I think that it might be confusing. For instance, I see no reason that a client wouldn't have a fixed configuration. A client that never races resumptions could send N and 1 always.
Can you please provide text?
NAME I can't really provide text as I'm unclear on what the field is trying to even describe.
Change:
6.1. <del> A DOH API client may utilize a hierarchy of caches that include both </del> <ins> A DNS API client may utilize a hierarchy of caches that include both </ins> HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the "Cache-Control no-cache" directive; however DNS caches do not have a similar mechanism.

Discussion:
Yipes, I thought I had found these in the last round. Thanks!
Even though the Terminology section contains "DNS API client" and "DNS API server" respectively, the -04 version of the draft still contains a few instances of "DOH client" and "DOH server". Not sure that's intended.
As well as one instance of "DOH API client" in Section 6.1
Change:
6.2.1. <del> The configuration agent distributes a list of QUIC versions to be served by the Retry Service. </del> <ins> See common-requirements. </ins> 6.2.2.

Discussion:
Hopefully this will close the gap between what we want Retry Services to do and reality.
It would help the anti-DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support. This provides a way to deploy new versions without having to upgrade the retry service software or hardware.
Change:
allocation policy (unchanged from RFC4366) is listed below: TLS ExtensionType Registry: Future values are allocated via IETF <del> Consensus RFC2434.  IANA has updated this registry to include the "signature_algorithms" extension and its corresponding value (see hello-extensions). </del> <ins> Consensus RFC2434.  IANA [shall update/has updated] this registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document.  IANA [shall update/has updated] this registry to include an "TLS 1.3" column with the following three values: "Clear", indicating that they shall be in the ServerHello "Encrypted", indicating that they shall be in the EncryptedExtensions block, and "Forbidden" indicating that they are not used in TLS 1.3.  This registry [shall be/has been] initially populated with the values in this document. </ins> This document also uses two registries originally created in RFC4492. IANA [should update/has updated] it to reference this document.  The

Discussion:
Does it make sense to just have a tri-state column for TLS 1.3 on the extensions registry: "key" - key determining parameters "encrypted" - encrypted "forbidden" - not for use in TLS 1.3
"go" as in whether they are plaintext or go into the EncryptedExtensions block.
Change:
These ciphersuites map to HPKE primitives and TLS signature schemes as follows I-D.irtf-cfrg-hpke RFC8446: <del> The hash used for HKDF computations in MLS is the same hash used in the HPKE KDF for the ciphersuite. </del> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only inlcude modern, yet well-established

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
non-member reroutes a connection from the client to the server on the same endpoint. <ins> Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively affects deployments.  For example, revocation of individual group members is not possible without changing the authentication key for all members. </ins> Entropy properties of external PSKs may also affect TLS security properties.  In particular, if a high entropy PSK is used, then PSK- only key establishment modes are secure against both active and

Discussion:
Builds on , and , and . cc NAME NAME NAME -- please review so we can submit today!
There are two numbered lists both of which only seem to have 1s? I see that you have removed the text on security weaknesses of PSKs (lack of identity protection/forward secrecy etc.) and also removed the reference to RFC 8773. I am completely fine with both as long as we provide a convincing answer to John's review.
Markdown handles the numbering for us. We have a section on identity protection, and the recommendations discuss forward secrecy, so I think more is redudant. No, that's still there.
John wrote: There also several weaknesses/limitation that are hinted at in RFC 8446 which apply for two-party PSK authenticated connections. As this is a guidance document for all uses of external PSK, I think this document should bring up and expand upon: Key Compromise Impersonation (KCI) resistance Protection of endpoint identities Forward secret with respect to long-term keys (psk_ke only) An additional security property given by signature authentication but not psk authentication is non-repudiation. As stated by Wikipedia “By this property, an entity that has signed some information cannot at a later time deny having signed it.”
This is a fair comment and I don't see any reason not to add these
NAME can you please send a PR?
Closing as resolved (by ).
The draft says “OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.” John wrote: I assume this is not the case for TLS 1.3 as the cipher suites in TLS 1.3 are independent of the authentication.
I guess it would help to clarify. In my opinion, we should only look at APIs of TLS 1.3.
I fixed this directly on main.
The draft currently says "It is NOT RECOMMENDED to share the same PSK between more than one client and server." John says: group PSK violates both “peer authentication” and “downgrade protection property”. It also violates “secrecy of the session keys”. Two-party PSK already does not provide “Key Compromise Impersonation (KCI) resistance” and “Protection of endpoint identities” and pskkey does not provide “Forward secret with respect to long-term keys”.

So when pskke is used in a group, the only property left is “Uniqueness of the session keys”...I am skeptical to introduce this new group PSK mode in an informal guidance document. If group PSK should be allowed, it should be more clearly declared as a new mode of TLS 1.3 and the security properties given and not given should be more clearly stated.
I guess John thinks NOT RECOMMENDED is not sufficient and we should stronger language like SHALL NOT.
Change:
hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: <del> The IdP's domain name </del> <ins> The RFC3986 at which the IdP's service is hosted.  Note that this may include a non-default port or a userinfo component, but neither will be available in a certificate verifying the site. </ins> The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to

Discussion:
This references RFC 3986 authority instead of providing a definition for IdP domain. This change means that userinfo sub-components are permitted, as are non-default ports, but also states that both are removed before matching against the certificate.
Change:
4.1.3. <del> The server chooses a connection ID length.  This MUST be at least one byte longer than the routing bytes. </del> <ins> The server chooses how many octets to reserve for its own use, which MUST be at least one octet. </ins> When a server needs a new connection ID, it encodes its assigned server ID in consecutive octets beginning with the second.  All other

Discussion:
follow-on to , also fixing
NAME asks if there is added value in expressing server ID lengths in bits instead octets. This is a bit of implementation complexity and a lot of churn in the spec and the handful of implementations that exist, but it does give the configuration agent a little more granularity. Does anyone find the value of this granularity to be compelling?
My thinking is that increasing/decreasing the server ID space by 256 is quite a large jump and could make config rotation a bit more complex. Adding an extra bit to the server ID doubles the number of IDs, which is a fairly widely used increase in data structures and algorithms.
While having such fine control would optimize for efficiency, splitting up bytes like this would complicate implementation. I'm also doubt that 1B of overhead is really going to affect anything. Closing this issue due to old age; can reopen if anyone wants to fight it out.
NAME proposed a PCID design that assigns SIDs on the fly instead of having to pre-configure them. There are drawbacks but it has some nice properties.
This is merged, but I'm going to take the question of what we can do with these dueling plaintext designs to the list.
List discussion was not helpful; closing this with the dynamic method still in the draft.