jiebi/CodeConvo huggingface dataset:
Code change:
(CID) to the DTLS record layer.  The presence of the CID is negotiated via a DTLS extension. <ins> Adding a CID to the ciphertext record format presents an opportunity to make other changes to the record format.  In keeping with the best practices established by TLS 1.3, the type of the record is encrypted, and a mechanism provided for adding padding to obfuscate the plaintext length. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- As an important part of this document is the padding, should it be mentioned also in the abstract ? -- Section 3 -- While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID." -- Section 6 -- I am puzzled by the text: "There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification." Does this mean that there is no way to update the peer IP address ? == NITS == -- Section 1 -- Please expand CID on first use outside of the abstract. -- Section 4 -- Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description.
Code change:
The User Equipment's access to the outside network continues uninterrupted <ins> 4.3. A different Captive Portal API URI could be returned in the following cases: If DHCP is used, a lease renewal/rebind may return a different Captive Portal API URI. If RA is used, a new Captive Portal API URI may be specified in a new RA message received by end user equipment. Whenever a new Portal URI is received by end user equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </ins> 5. The authors thank Lorenzo Colitti for providing the majority of the

Related discussion:
text: Just realized that, this section may also apply to the case of initial provisioning of Portal URI if multiple ways are used, such as: DHCPv4/DHCPv6/RA could be used at the same time, and they return different values; to quote 7710bis: However, if the URIs learned are not in fact all identical the captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs. Specifically, URIs learned via any of the options in Section 2 should take precedence over any URI learned via some other mechanism, such as a redirect. Shall we mention anything on the initial provisioning case too here? or that will only in 7710bis?
Probably not a lot, except that future requests might go there. Because we don't hold any state for these resources, that's probably OK.
NAME do you think that you could take a swing at this?
By portal URI, you meant the URL to the json file? If so, it seems the ways how it could be changed are: In the case of DHCPv4/v6,in a renewal/rebind of DHCPv4/v6 lease, the end user equipment could receive a new portal URI in the DHCP renew/rebind response. In the case of RA, the end user device may receive a new portal URI in a new RA message. (In RA case, is it possible that there are multiple RA servers sending out different portal URI?) Is there any other possibilities? Do I understand correctly that you are suggesting add something like the following? If a new Portal URI is provided via DHCPv4/v6 renew/rebind or RA, use the new one. Where shall we add this section please? a new paragraph under 2.2.1. DHCP or Router Advertisements? or a new sub section 4.3 under 4 Solution Workflow?
Right. I forget whether this was about the API URL (the JSON) or the user portal URL. In either case, they can change and I think that's OK. The RA case is interesting in the sense that it might imply a different router advertising different coordinates, as you say, but if it is the same router, then that should be regarded as a change. This came up in discussion and some people felt that it needed to be acknowledged.
Code change:
The User Equipment's access to the outside network continues uninterrupted <ins> 4.3. A different Captive Portal API URI could be returned in the following cases: If DHCP is used, a lease renewal/rebind may return a different Captive Portal API URI. If RA is used, a new Captive Portal API URI may be specified in a new RA message received by end user equipment. Whenever a new Portal URI is received by end user equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </ins> 5. The authors thank Lorenzo Colitti for providing the majority of the

Related discussion:
text: Your suggested outcome is probably the only sensible one: if you need to contact the API, use the most recent value you have. As for location in the document, a new Section 4.x describing how updated details can be acquired seems right.
Fixed in
Thanks for doing this. I have a few small suggestions.Looks good. Thanks!
Code change:
packet is visible to the network.  Therefore stream multiplexing is not intended to be used for differentiating streams in terms of network treatment.  Application traffic requiring different network <del> treatment SHOULD therefore be carried over different five-tuples </del> <ins> treatment should therefore be carried over different five-tuples </ins> (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to

Related discussion:
text: note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.
Code change:
CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting <del> amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint maintains for a closing </del> <ins> amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing </ins> connection, endpoints MAY send the exact same packet. Allowing retransmission of a closing packet is an exception to the

Related discussion:
text: We weren't very concrete in saying how endpoints generate packets with CONNECTIONCLOSE, particularly those that throw away keys. We have a rather vague requirement. In short, follow the same rules we established for the handshake. Wording this as an aggregate number allows for stochastic reactions and larger CONNECTIONCLOSE frames. This way, if you get a 25-byte packet and respond with a 200-byte packet, you can do that, but you have to respond to 3 in 8 or fewer in that way. Note that this limit only applies if the endpoint throws away decryption keys. Endpoints with keys aren't blind amplifiers.
closing period ({{draining}}) and send a packet containing a CONNECTIONCLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets. To avoid creating an unwitting amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTIONCLOSE frame. To This seems like a pretty vague requirement for a 2119 MUST. Like, I could only send it 9999/10000 packets and that would be compliant.
I think that it would be good to follow the 3x rule here also, but that's a non-editorial change.
Do folks agree the PR resolves this?
I think the PR resolves this and is a sensible choice.
Yup, the PR resolves this.
OK, labelling as such.
Code change:
12. <del> Having discussed Transport Properties in connection-props and listed a number of Message Properties ("Ordered", "Idempotent" etc.) in message-props, we now provide a complete overview of a transport system's defined Transport Properties. Properties are structured in two ways: </del> <ins> Having discussed Selection Properties in selection-props, Connection Properties connection-props, and Message Properties (message-props), we now provide a complete overview of a transport system's defined Transport Properties. </ins> <del> By how they influence the transport system, which leads to a classification into "Selection Properties", "Protocol Properties", "Control Properties" and "Intents". </del> <ins> Transport Properties are structured by the phase and object they are applied: - Selection Properties apply to Preconnections - see selection-props - Connections Properties apply to Connections - see connection-props - Messages Properties apply to Messages - see </ins> <del> By the object they can be applied to: Preconnections, see connection-props, Connections, see introspection, and Messages, see message-props. Because some properties can be applied or queried on multiple objects, all Transport Properties are organized within a single namespace. </del> <ins> All Transport Properties are organized within a single namespace. This enables setting them as defaults in earlier stages and querying them in later stages: - Connections Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages. </ins> Note that it is possible for a set of specified Transport Properties to be internally inconsistent, or to be inconsistent with the later

Related discussion:
text: This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.
Code change:
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Paths, </del> <ins> "null").  These can be obtained via literal values; Singular Queries, </ins> each of which selects at most one node the value of which is then used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv).

Related discussion:
text: XPath terminology is a bit weird, because XPath has a somewhat competing standard XQuery... XPath is based on DSSSL, which had a complex expression language for building paths in the XML trees that was based on the Scheme language. (Which is the experience that makes me hesitant just jumping headlong into another expression language...)
LGTM with that change. Thanks!
Code change:
Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the working <del> group. A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf- <wgname>-wg. </del> <ins> group.  A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf-<wgname>-wg. </ins> A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much

Related discussion:
text: I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.
Code change:
Change controller: n/a <del> 3.3. </del> <ins> 2.2.2. The following information serves as the registration form for the "application/openapi+yaml" media type. </ins> Type name: application

Related discussion:
text: introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME
Code change:
This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a <del> closure alert has been received MUST be ignored. </del> <ins> closure alert has been received MUST be ignored.  This alert MUST be sent with AlertLevel=warning. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a

Related discussion:
text: closenotify has always used a warning alert level, but this is not actually written down anywhere. It seems to have gotten lost as early as RFC 4346 (TLS 1.1!). In RFC 2246, there is some text that mentions the correct level is warning as an aside in describing something else. I wasn't able to find any other text that discussed this. Then, RFC 4346 dropped the session termination behavior: But in doing so, it dropped any mention of which alert level to use. That text has carried over to RFC 8446 as: In RFC 8446, we said alert levels no longer matter and can be "safely ignored", but this still leaves unspecified what the sender should do. Skimming implementations, both BoringSSL and NSS will treat "fatal" closenotify as an error, so using "warning" is also necessary for interop.
Code change:
SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by <del> transport protocols RFC8923. </del> <ins> transport protocols RFC8923.  If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match. </ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via

Related discussion:
text: URL Assuming there would be more protocols in the future and the minset functionalities will expand via extension or amendments. It would important to indicate if this architecture should is also extensible or it only supports on the minimum set referred. Definitely we haven't seen the future yet, but it would be important to express if we have considered such expansion of minimum functionalities.
To me, the current spec is based on minset that describes the common functions. So, the addition I would expect here is to say that there can be extensions and protocol-specific features.
I expect that if a common feature is added to the minset, then the architecture and API surface would also be extended to match.
LGTM modulo a nit
Code change:
responds with an error status code and a problem document describing the error. <del> 7.3.4. </del> <ins> 7.3.7. </ins> A client can deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do

Related discussion:
text: This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.
Code change:
7. The data payload for the application/dns-message media type is a <del> single message of the DNS on-the-wire format defined in section 4.2.1 </del> <ins> single message of the DNS on-the-wire format defined in Section 4.2.1 </ins> of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used <del> in RFC7858 (which uses the format defined in section 4.2.2 of </del> <ins> in RFC7858 (which uses the format defined in Section 4.2.2 of </ins> RFC1035). DoH clients using this media type MAY have one or more EDNS options

Related discussion:
text: Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?
NAME That could be added, but it would need a lot more text because your proposed text only deals with one layer (HTTP) while the text above it also talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can decide whether adding recommendations for just one layer is worthwhile or possibly misleading about the overall privacy.
NAME It was only an example, and I would be happy to expand. That said, I think this is the most likely source of leakage: folks using a general purpose HTTP subsystem that carries information not needed for DOH requests. Actually recommending data minimization there, rather than saying "it should be considered" seems like a worthwhile thing to do in my personal opinion.
Agreed with Ted (on the list) that this conversation should be on the list. Locking it here.
I have unlocked the comments so that people can propose specific wording changes as diffs in the PR itself; most questions and suggestions should be done on the list.
Code change:
The client's TLS ClientHello may contain a Server Name Indication (SNI) RFC6066 extension, by which the client reveals the name of the server it intends to connect to, in order to allow the server to <del> present a certificate based on that name.  It may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </del> <ins> present a certificate based on that name.  SNI information is available to unidirectional observers on the client-to-server path, if present. The TLS ClientHello may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </ins> Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-

Related discussion:
text: "Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ?
Not sure if we add something because I think it okay to state assumptions...
"unless noted" states that we'll note when something is unidirectionally observable, I'm reviewing the language now to see if we missed any...
Code change:
All SenML Records in a Pack MUST have the same version number.  This is typically done by adding a Base Version field to only the first <del> Record in the Pack. </del> <ins> Record in the Pack, or by using the default value. </ins> Systems reading one of the objects MUST check for the Version field. If this value is a version number larger than the version which the

Related discussion:
text: As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM
Code change:
reordered ack-eliciting packet.  This extension modifies this behavior. <del> If an endpoint has not yet received an ACK_FREQUENCY frame, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC- TRANSPORT.  An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </del> <ins> In order to ensure timely loss detection, the Reordering Threshold provided in the ACK_FREQUENCY frame SHOULD NOT be larger than the re- ordering threshold used by the data sender for loss detection. (Section 18.2 of QUIC-RECOVERY) recommends a default packet threshold for loss detection of 3. An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </ins> If the most recent ACK_FREQUENCY frame received from the peer has a "Reordering Threshold" value of 0x00, the endpoint does not make this

Related discussion:
text: Sec #ack-frequency-frame says: and Sec #out-of-order says:
It seems optimal to default it to 3, because that's the default packet threshold, but the principle of least surprise argues for 1 (ie: no behavior change until an ACK_FREQUENCY frame is received), so I lean toward 1.
This PR adds a SHOULD NOT, but it seems sensible.