jiebi/CodeConvo huggingface dataset:
Change:
that contain packets that are all discarded. Clients MUST ensure that UDP datagrams containing Initial packets <del> have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary.  A client that sends padded datagrams allows the server to send more data prior to completing address validation. </del> <ins> have UDP payloads of at least 1200 bytes, adding PADDING frames as necessary.  A client that sends padded datagrams allows the server to send more data prior to completing address validation. </ins> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake

Discussion:
Changes to explain Padding == PADDING Frame
Thanks again Gorry.
I have a long comment on a scattered observation that could be very simple to fix: In section 6, it wasn’t clear what were the ways that "padding" could be performed. There could be various ways - simply leave UDP payload unused, fill it with coalesced QUIC packets, add padding and other frames, etc and when the text says this I think it’s unclear to me what is expected - any or all of these, but it doesn't seem to be said. e.g.: /Clients that support multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support. / Is the assumption here, more like: /Clients that support multiple QUIC versions SHOULD coalesce QUIC packets or add PADDING frames to pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support. / … rather than some other technique to pad-out the datagram payload? See also: /Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary. A client that sends padded datagrams allows the server to send more data prior to completing address validation./ and later: /In particular, an endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum Transfer Unit (PMTU) discovery / So, I think the topic of padding needs a tiny bit more clarification - it’s almost there, but maybe a sentence that explicitly explains the permitted options in section 14 would be good, which could be cited rather than this scattered mention of “pad-out”
Perhaps these mentions of the word "padding" just need to reference section 19.1. "PADDING Frames" ?
Yes a REF is good: If that is all that is intended, we should say so.
Agreed, I think the right phrasing is PADDING Frames, though I don't think we need to reference 19.1 in every spot we talk about PADDING frames.
So could we grep for Padding and ensure we say /PADDING Frame/? - I guess the REF first time used would be good - if not already there?
How about something like: PR ?
Closing now that we have .

The commas for parentheticals got a little awkward there. Otherwise, this is a good change.I've done a bit of editorializing, and this LGTM. NAME should take a look.
Change:
6. <ins> IANA is requested to create a registration for an "application/ captive+json" media type (iana-json) and a registry for fields in that format (iana-field-reg). 6.1. </ins> This document registers the media type for Captive Portal API JSON text, "application/captive+json".

Discussion:
As discussed in , define an IANA registry for extending JSON keys use for Captive Portal API.
NAME NAME thanks for the comments. Please take another pass!
Should we define an IANA registry for adding new keys?
Yes, yes we should.
and i already commented in the PR, but if possible it would be beneficial to have some distinction between IETF or a relevant organization (like WFA, WBA) requested keys vs from some individual organization
Would we want to suggest having a nested dictionary format for organization-specific extensions? Like "wba" as a key to a dictionary; or a sub-dictionary indicating that there are WISPr-related settings to be aware of?
i think it would be a good idea. We have seen WBA start to take active interest in the documents. Also there's work happening in WFA that could benefit from having an extension point
RFC 6648 might suggest otherwise. If there are things that a group wants to add that are truly unique to that group, this is probably fine.
Yes, I think that more than having per-group keys (with almost certain overlap), I'd imagine that compatibility with certain technologies would be handled via these sub-dictionaries, such as what I mentioned for WISPr. Not sure how critical mentioning this is in the document though.
Can we call this one done?
I'm assuming we will go down the path of defining an IANA registry with access technology specific extension ?
The description in "Captive Portal API Keys Registry" gives some guidance for prefixes, etc. I assume the experts once designated can work with WFA/WBA to define proper entries.
Change:
IANA is requested to create the following three entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(0xfe0b), with "TLS 1.3" column values set </del> <ins> encrypted_client_hello(0xfe0c), with "TLS 1.3" column values set </ins> to "CH, HRR, EE", and "Recommended" column set to "Yes". ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set

Discussion:
To be included with . Note that this is a wire-breaking change that should have landed in draft-11, but didn't.
NAME since this will go into the next version of the draft, can we bump everything to the next version here?
Done.
Thanks!
ECHConfig is defined as but the text below it says The intention was to bump ECHConfig.version from 0xfe0a to 0xfe0b for draft-11, but this got missed by URL (I wrote the PR, so I apologize for my part in missing this.) How do folks think we should resolve this? Do we need to cut a new draft with the ambiguity fixed?
Oh whoops, nice catch! Using definitely won't work since the format and corresponding ClientECH extension has changed. I suppose all the implementors could just agree to mentally fix this typo when reading the draft, but may as well cut draft-12. Draft numbers are cheap.
We could try to pick up some editorial changes, too, like those suggested in .
I'd also personally be pretty happy to have in there, but also fine to skip it for what's supposed to be a small bugfix draft snapshot.
+1 I've not checked recent editorial changes but they're probably fine too. S
I'd be happy to take in draft-12 as well, though I'm inclined to think this should strictly be a bugfix/editorial draft. I'd say let's wait until Chris W. gets off back from PTO and let him make the call. Unless we're in a hurry, in which case we could ping one of the other authors to merge our changes and cut a draft.
Closing as resolved.
Change:
Data Unit: Byte-stream <del> the Transport Services API mappings for MPTCP are identical to TCP. </del> <ins> The Transport Services API mappings for MPTCP are identical to TCP. </ins> MPTCP adds support for multipath properties, such as "multipath" and "multipathPolicy".

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!
Change:
The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path <del> "/.well-known/coap" RFC5785.  The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </del> <ins> "/.well-known/coap" RFC5785.  The present specification formally updates RFC6455, extending the well-known URI mechanism defined in RFC5785 to also cover the "ws" URI scheme defined in that document. The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986.

Discussion:
Doesn't this need an IANA considerations section - URL
We are not creating a registry here; we are extending the semantics of the existing registry created by RFC 5875 to two existing URI schemes. No IANA action required. (We do have an IANA action for registering in that existing registry.)
I was thinking of something like this - URL
Yes -- URL
Doh. For some reason, I got hung up on needing a separate reference for RFC6455, but only the URI suffix is registered. I can appreciate that the lack of a separate draft could be confusing based on the layout of the registry - which will only reference coap-tcp-tls. Sorry for the noise.
: Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use ...
Change:
If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to <del> satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </del> <ins> satisfy the limits.  Downscaling MUST NOT change the picture aspect ratio of the encoding, ignoring any trivial differences due to rounding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST

Discussion:
LGTM.
In spite of what was said at the W3C WebRTC WG virtual meeting yesterday I think the aspect ratio preservation can be an issue also in context of . Just to take as example that the video resolution of the track is 595 by 753 (e.g. capturing a part of the screen) and has limited what can be transmitted to 480 by 640. Scaling according to JSEP section 3.6 (if I read right) gives a transmission resolution of 480 by 607.4621.. but since we can't transmit fractional pixels we would transmit 480 by 607 and have a slight aspect ratio mismatch. The spec should clarify what to do in situations like this.
OK, perhaps then we change this text: the encoder SHOULD apply downscaling in order to satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding. to allow for rounding.
Makes sense to me.
LGTM
Change:
A TLSCiphertext record was received that had a length more than <del> 2^14+2048 bytes, or a record decrypted to a TLSPlaintext record </del> <ins> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </ins> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

Discussion:
As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.
Change:
send the contents of push messages as they are sent by application servers. <ins> A user agent MAY include a Urgency header field in its request.  The push service MUST only deliver messages with an urgency greater than or equal to the value of the header field as defined in the urgency_values. </ins> Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the

Discussion:
Should we include a reference to URL - perhaps in Acknowledgements?
I don't care about acknowledgments for -nice. But I do care about the issues that I raised on the list.
Change:
upon topic creation.  The lifetime of a topic MUST be refreshed upon create operations with a target of an existing topic. <del> Topic hierarchies can be created by creating parent topics.  A parent topic is created with a POST using ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690, such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link serialization, that topic may then have sub-topics created under it as shown in create-sub-fig. </del> The CREATE interface is specified as follows: Client -> Broker

Discussion:
removed duplicate description of hierarchy, added a constraint to allow only one topic to be created at a time, added text to allow additional target attributes in links for created topics
Change:
browsing history.  Depending on the deployment model, separating these contexts can take different forms.  The Origin, Attester, and Issuer portrayed in fig-overview can be instantiated and deployed in <del> a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations. </del> <ins> a number of ways. This section covers some expected deployment models and their corresponding security and privacy considerations.  Each deployment model is described in terms of the trust relationships and communication patterns between Client, Attester, Issuer, and Origin. </ins> The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
the cardinality of the relations.  The relations between the values of the attributes are explained in the interface sections. <ins> Some of the attribute values are URIs.  Those values are always full URIs and never relative references in the data model.  They can, however, be expressed as relative references in serializations, and often are. </ins> The model shown in fig-ER-WKC models the contents of /.well-known/ core which contains:

Discussion:
This is the first step to closing [54], doing the changes to the model itself. Won't close the issue by itself probably, as some other portions might mention the model. This does not try to address any of the open issues. [54]: URL
s taget/target/
Change:
IANA is requested to add ekt_key as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) <del> Parameters" registry with a reference to this specification, a DTLS- OK value of "Y", and allocate a value of TBD to for this content type. </del> <ins> Parameters" registry: </ins> [[ Note to RFC Editor: TBD will be allocated by IANA. ]]

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with its AggregateInitializeReq message as the payload.  The media type is <del> "message/ppm-aggregate-initialize-req".  In addition, this request </del> <ins> "message/dap-aggregate-initialize-req".  In addition, this request </ins> MUST be authenticated as described in https-sender-auth. 4.3.1.2.

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
acknowledged at the connection level with a DATA_ACK.  Further details are in sec_close. <del> There is an additional method of connecton closure, referred to as </del> <ins> There is an additional method of connection closure, referred to as </ins> "Fast Close", which is analogous to closing a single-path TCP connection with a RST signal.  The MP_FASTCLOSE signal is used to indicate to the peer that the connection will be abruptly closed and

Discussion:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.
Change:
which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the <del> "ticket_age_add" value that was included with the ticket, see NSTMessage modulo 2^32.  This addition prevents passive observers </del> <ins> "ticket_age_add" value that was included with the ticket (see NSTMessage), modulo 2^32.  This addition prevents passive observers </ins> from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
client. The field is an Item and its value is a non-negative Integer <del> expressed in service-limit.  Parameters are not allowed. </del> <ins> expressed in service-limit.  This specification does not define Parameters for this field.  If they appear, they MUST be ignored. </ins> This field can be sent in a trailer section.

Discussion:
Parameters are not allowed, and if they appear they MUST be ignored.
Why not just 'If Parameters appear they MUST be ignored'?
NAME we wanted to stress the fact that servers are not expected to provide parameters, otherwise some clients could just consider the whole field value malformed and ignore it.
The normal way to do that is something like:
Ok, I'll rebase this PR tomorrow :) Late night now in Italy. Thanks for all this support :)
In a few places, the specification says "Parameters are not allowed" but does not spell out what should happen if they appear.
Change:
3.1. <del> The "Idempotency-Key" request header should be added to the permanent registry of message header fields (see RFC3864), taking into account the guidelines given by HTTP/1.1 RFC7231. </del> <ins> The Idempotency-Key field name should be added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry". </ins> 4.

Discussion:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.
Change:
BGP (I-D.ietf-idr-bgp-model) <del> PIM (I-D.liu-pim-yang) </del> <ins> PIM (I-D.ietf-pim-yang) </ins> NAT management (RFC8512)

Discussion:
PIM ([I-D.liu-pim-yang]) is outadated
see
URL
Closed with commit
Change:
2.5.1. Interaction start modes are specified by a string, which consists of <del> the start mode on its own, or by a JSON object with one required field and any number of optional parameters defined by the mode: </del> <ins> the start mode name on its own, or by a JSON object with one required field and any number of parameters defined by the mode. </ins> <del> Individual modes MAY define additional parameters to be required in the object. </del> <ins> Individual modes defined as objects MAY define additional parameters to be required in the object. </ins> This specification defines the following interaction start modes:

Discussion:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc
Change:
See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for <del> applications using QUIC, as well. </del> <ins> applications using QUIC, as well.  Considerations on linkability, replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee

Discussion:
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.
Minor editorial nit.