jiebi/CodeConvo huggingface dataset:
Change:
server "user-portal-url" (required, string): provides the URL of a web <del> portal that can be presented a user to authenticate </del> <ins> portal that can be presented to a user to interact with </ins> <del> "expire-date" (optional, datetime): indicates the time at which the Captive Portal is expected to close </del> <ins> "expire-date" (optional, string formatted as RFC3339 datetime): indicates the date and time after which the host will be in a captive state </ins> "bytes-remaining" (optional, integer): indicates the number of <del> bytes left, after which the Captive Portal is expected to close </del> <ins> bytes left, after which the host will be in a captive state </ins> Note that the use of the hmac-key is not defined in this document, but is intended for use in the enforcement step of the Captive Portal

Discussion:
Removed language for /.well-known URI. Made serving over port 443 a SHOULD requirement. Other editorial changes
Added your updated language, should be good to go.
I don't think that we need this. 7710 gives us an entire URI, as can PvD.
I agree that we can use the URI from the DHCP option or from PvD. The reason I went this route was to avoid the scheme that was in the API draft to start with, which seemed to be: If you access the 7710 URI with a GET, you'll receive the HTTP for the user interactive portal If you access the 7710 URI with a POST, you'll get the JSON API That seemed problematic (a) because it implies the user portal and API are co-located and (b) it seemed overly complex. Do you have a preference for what methods are valid to access the JSON API, and whether we should specify that the URI needs to be JSON? My concern was that if the DHCP option or whatever pointed to something that was clearly .html, something's wrong, and using a well-known JSON URI to compare against would be a way to detect that.
NAME Thoughts on the method for fetching the JSON API, or if that's a non-issue?
Let's take this to the list.
PR fixes the well-known URI language. For now there is indication of Accept and Conent-Type header usage but we haven't explicitly called it out until we get a final decision. We can close this issue though.
Change:
"[{"j": 4}, {"k": 6}]" must appear before "{"j": 4}" and "{"k": 6}", <del> "{"j": 4}" must appear before "4", and </del> <ins> "{"j": 4}" must appear before "{"k": 6}", </ins> <del> "{"k": 6}" must appear before "6". </del> <ins> "{"k": 6}" must appear before "4", and "4" must appear before "6". </ins> The example above with the query "$.o..[*, *]" shows that a selector may produce nodelists in distinct orders each time it appears in the

Discussion:
URL
This change looks good, thank you. I have one more, though (looking more closely at the diagnostics): I don't think the "Alternative result" can be generated, as outside arrays come before inside arrays.
Yes, nodes are visited before their descendants. Fixed in 1b85e02c7a5e60ba87ab1c455502c66816327f9d.
URL
Change:
connection ID length between 17 and 20 octets.  The server writes its provided server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional <del> information, and MUST differ between connection IDs.  Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </del> <ins> information, and MUST differ between connection IDs.  The encrypted arbitrary bits MUST be unique for each CID the server generates; the easiest way to do so is to start the nonce at zero and simply increment by one for each CID. Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </ins> The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher.

Discussion:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.
Change:
solution that uses nonces and thus does not require that any clocks are synchronized. <ins> As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. Thus we use a suffix (a for Attester, v for verifier, and r for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </ins> In this example solution, the Verifier can check whether the Evidence <del> is fresh at time(RG) by verifying that "time(RG) - time(NS) < </del> <ins> is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < </ins> Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to <del> correctly provide the delta time(EG)-time(VG), then it can determine recency by checking "time(RG)-time(NS) + time(EG)-time(VG) < Threshold". </del> <ins> correctly provide the delta "time(EG_a)-time(VG_a)", then it can determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < Threshold". </ins> Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the <del> Attestation Result is fresh by checking "time(OP) - time(NS') + time(RR)-time(EG) < Threshold".  Although the Nonce2 and time(RR)- time(EG) values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. </del> <ins> Attestation Result is fresh by checking "time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) < Threshold".  Although the Nonce2 and "time(RR_a)-time(EG_a)" values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. </ins> The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a <del> validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(NS') < time(RX)-time(RG)". </del> <ins> validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". </ins> 15.3.

Discussion:
Per offline discussion between Henk and Dave, trying this annotation to see if it helps Also try combining VG and AA into VC since nothing in doc uses AA, and any example could use either VG or AA, so combining makes any example work for both. Signed-off-by: Dave Thaler
Change:
undesirable.  Operators can avoid these concerns by setting "template.handshakeFraming = true". <ins> On unreliable transports, the DTLS 1.3 ACK system is used. </ins> 2.3.2. TLS and DTLS start the handshake with an empty transcript.  cTLS is

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
1. <del> The present specification defines an interoperable regular expression </del> <ins> This specification describes an interoperable regular expression </ins> flavor, I-Regexp. This document uses the abbreviation "regexp" for what are usually

Discussion:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by
Change:
"leaf_node_source" is set to "key_package". If the LeafNode appears in an Update proposal, verify that <del> "leaf_node_source" is set to "update". </del> <ins> "leaf_node_source" is set to "update" and that "encryption_key" represents a different public key than the "encryption_key" in the leaf node being replaced by the Update proposal. </ins> If the LeafNode appears in the "leaf_node" value of the UpdatePath in a Commit, verify that "leaf_node_source" is set

Discussion:
This PR fixes small issues that I noticed while implementing proposal validation and fixing some external join bugs: The pseudocode for determining whether a path is required assumes that all proposals are by-reference. The PR updates the pseudocode to be more general, and also account for proposals by value. There were two references to adding a single leaf to the tree, which are updated to make clear that the tree grows by doubling, not by single leaves. There was no current requirement that an Update proposal have a distinct , so one is added.
Change:
close_notify is more appropriate.  This alert should be followed by a close_notify.  This message is generally a warning. <del> no_renegotiation Sent by the client in response to a ServerHello or </del> <ins> no_renegotiation Sent by the client in response to a HelloRequest or </ins> by the server in response to a ClientHello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously established connection; TLS 1.3 removes this feature.

Discussion:
Sorry 'bout all that me re-learning git again.
Assuming I've learned git properly, fixing the above should just be: git reset --hard HEAD~2 git push -f (done on this branch, of course; check branch log before pushing!)
Whenever you do a , always, ALWAYS specify a destination. You can be screwed by your config if you don't. The alternative is to do this: and open a new pull request. No force pushes that way (just a dead branch somewhere).
Change:
The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When <del> acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </del> <ins> acting as answerer, the implementation will reject any m= section that does not contain an "a=rtcp-mux" attribute. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to

Discussion:
Also restructured the "rejecting media descriptions" sections since there are now four things that can cause it to be rejected.
I think this does a good job clarifying these edge cases and is the behavior we want.
lgtm
LGTM
I just realized this may not be complete. Even if max-bundle is used, shouldn't one media description be accepted? This would ensure the same result regardless of whether the max-bundle endpoint is the offerer or answerer. It would also prevent a remote offer from being rejected if it didn't include a "BUNDLE" group simply because there was only one media description.
Deficiencies should be addressed by this PR (apologies for missing them on the first pass): URL
Change:
or Handshake packets. Section 4 of QUIC-TLS provides more detail about these restrictions. <del> Note that all frames can appear in 1-RTT packets. </del> <ins> Note that all frames can appear in 1-RTT packets.  An endpoint MUST treat receipt of a frame in a packet type that is not permitted as a connection error of type PROTOCOL_VIOLATION. </ins> The "Spec" column in frame-types summarizes any special rules governing the processing or generation of the frame type, as

Discussion:
error of type FRAMEENCODINGERROR. What about a frame of an impermissible type for this key space?
URL
This seems to only apply to 0-RTT, but there are lots of frames which may not appear in Initial
Change:
by off-path attackers.  QUIC versions MUST define a mechanism that authenticates the values it contains. <del> 7. </del> <ins> 8. </ins> This document makes no request of IANA. <del> 8.  References </del> <ins> 9.  References </ins> <del> 8.1.  URIs </del> <ins> 9.1.  URIs </ins> [1] mailto:quic@ietf.org

Discussion:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.
Change:
network operators may be using to troubleshoot HTTP streaming media performance issues, perform analytics, or even intercept exchanges in current applications will not work for QUIC-based applications <del> without making changes to their networks. </del> <ins> without making changes to their networks. stream-encrypt-media describes the implications of media encryption in more detail. </ins> While QUIC is designed as a general-purpose transport protocol, and can carry different application-layer protocols, the current

Discussion:
I did add a few paragraphs of text, but don't expect it to be too controversial. Any thoughts?
Needs to be edited and possibly some text migrated.
Change:
policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. <del> If the RtpSender of the RtpTransceiver associated with this m=section is active: </del> <ins> If the RtpTransceiver has a sendrecv or sendonly direction: </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.

Discussion:
Reference transceiver direction as opposed to "active" senders/receivers We initially thought there would be an "active" bit on senders/receivers to control the direction of a media description, but instead we now have a "setDirection" API on the transceiver. So we should reference that.
lgtm
Change:
secrecy (PFS). Data in the first flight sent by the client in a connection <del> established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as </del> <ins> established with 0-RTT MUST be idempotent (as specified in Section 5.6 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as </ins> idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications:

Discussion:
The ops drafts often reference the core drafts by section number; make sure these section number references are correct for the WGLC drafts.
Correcting overcorrections regarding capitalization, but this seems benign.
Change:
authentication of a card holder to online services with TLS-PSK SmartCard. <ins> Quantum resistance: Some deployments may use PSKs (or combine them with certificate-based authentication as described in RFC8773) because of the protection they provide against quantum computers. </ins> There are also use cases where PSKs are shared between more than two entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova):

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:
The following terms are used: <del> client: The endpoint initiating the TLS connection. </del> <ins> client: The endpoint initiating the DTLS connection. </ins> connection: A transport-layer connection between two endpoints.

Discussion:
Add references to RFC 768: UDP RFC 4347: DTLS 1.0 RFC 4346: TLS 1.1 RFC 6347: DTLS 1.2 RFC 5246: TLS 1.2 in the Introduction section. Currently they are mentioned but with no citations.
Change:
Note that this encapsulation works equally well with IPv4, IPv6, and IPv6-based Segment Routing I-D.ietf-6man-segment-routing-header. <del> S-Labels, d-CW and zero or more F-Labels are used as defined in I- D.ietf-detnet-mpls and are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it too is not modified. </del> <ins> S-Labels, A-Labels (when present), d-CW and zero or more F-Labels are used as defined in I-D.ietf-detnet-mpls and are not modified by this document. </ins> 4.

Discussion:
IESG review comments resolved in this version
MPLSoUDP
MPLSoUDP: all 01-27 changes done.
can be merged once comments integrater, per Jan 27th meeting
Change:
closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. <del> Applications must be slightly rethought in order to make best use of 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </del> <ins> An application needs to deliberately choose to use 0-RTT, as 0-RTT carries a risk of replay attack.  Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP- REPLAY. </ins> <del> 3.2. </del> <ins> 3.1. </ins> Retransmission or (malicious) replay of data contained in 0-RTT packets could cause the server side to receive two copies of the same

Discussion:
This cuts a section heading and coalesces a few paragraphs. It adds a point of comparison with TLS 1.3.
Section 3 talks about the challenges of 0-RTT, but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP. I think I'd reword this to talk about the similarity, and that while QUIC gives Early Data more visibility, the same cautions and mitigations still apply. (I'd also probably find a more technical title than "Here There Be Dragons," but that's purely stylistic.)
I agree that challenges are similar to TLS1.3 over TCP. However, given this document is scoped to the use of QUIC, I'm not sure what mentioning TCP in this section gets you. I find the section actually quite clear without mentioning anything about TCP. Or did I miss the point you are making?
Otherwise PRs are always welcome! :-)