jiebi/CodeConvo huggingface dataset:
Change:
Section 3.2.1).  The endpoint name MUST NOT contain any character in the inclusive ranges 0-31 or 127-159.  The maximum length of this parameter is 63 UTF-8 encoded bytes.  If the RD <del> is configured to recognize the endpoint (e.g. based on its security context), the RD assigns an endpoint name based on a set of configuration parameter values. </del> <ins> is configured to recognize the endpoint to be authorized to use exactly one endpoint name, the RD assigns that name.  In that case, giving the endpoint name becomes optional for the client; if the client gives any other endpoint name, it is not authorized to perform the registration. </ins> Sector (optional).  The sector to which this endpoint belongs. When this parameter is not present, the RD MAY associate the <del> endpoint with a configured default sector or leave it empty. The sector is encoded like the ep parameter, and is limited to 63 UTF-8 encoded bytes as well.  The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. </del> <ins> endpoint with a configured default sector (possibly based on the endpoint's authorization) or leave it empty.  The sector is encoded like the ep parameter, and is limited to 63 UTF-8 encoded bytes as well. </ins> Lifetime (optional).  Lifetime of the registration in seconds. Range of 1-4294967295.  If no lifetime is included in the

Discussion:
This also answers the repeated questions that were asked about conflicts between recognized and given ep names, and brings the wording in line with the more consistent application of the security glossary.
Change:
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the <del> ServerKeyExchange message it MUST abort the connection with handshake_failure or insufficient_security alert. </del> <ins> ServerKeyExchange message and it sent one in signature_algorithms extensions it MUST abort the connection with handshake_failure or insufficient_security alert.  If client did not send MD5 nor SHA-1 hash algorithm in signature_algorithms extension and it receives a MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the connection with the illegal_parameter alert. </ins> 5.

Discussion:
replying with handshakefailure when server breaks protocol invariants isn't a good idea, make the behaviour conditional on values in signaturealgorithms (since this is the normal behaviour a client should exhibit when a signature algorithm is disabled, this does not actually increase complexity of the implementation)
Change:
ID Length, Key, and Zero-Padding Length.  The Server ID is unique to each server, but the others MUST be global. <ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order. </ins> A full QUIC-LB configuration MUST also specify the information content of the first CID octet and the presence and mode of any Retry Service.

Discussion:
Updated the test vectors for the latest version of the spec, added PCID, and made them usable to test server implementations.
Change:
We sometimes refer to this message as the _report_. The message contains the "task_id" of the previous request.  It also includes the <del> time (in seconds since the beginning of UNIX time) at which the report was generated.  This field is present to ensure that each report is included in at most one batch.  The rest of the message consists of the encrypted input shares, each of which has the following structure: </del> <ins> time at which the report was generated.  This field is present to ensure that each report is included in at most one batch.  The rest of the message consists of the encrypted input shares, each of which has the following structure: </ins> "config_id" is equal to "HpkeConfig.id", where "HpkeConfig" is the aggregator's key config.

Discussion:
Introduces and definitions, principally to make it more obvious that is a number of seconds.
Yeah, this is a nice improvement. I'd keep Time and Duration colocated so we can more clearly define in terms of the other.Good idea!
Change:
"a=fmtp" line that references the payload type of the primary codec, as specified in RFC4588, Section 8.1. <del> For each supported FEC mechanism that is present in the offer, a corresponding "a=rtpmap" line indicating the desired FEC codec. </del> <ins> For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The FEC mechanisms that MUST be supported are specified in I-D.ietf-rtcweb-fec, Section 6, and specific usage for each media type is outlined in Sections 4 and 5. </ins> "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4.

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
When an implementation is asked to Listen, it registers with the system to wait for incoming traffic to the Local Endpoint.  If no <del> Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error. </del> <ins> Local Endpoint is specified, the implementation should use an ephemeral port. </ins> If the Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object

Discussion:
Done.
Impl draft section 4.6 (Implementing listeners): "If no Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error." Do we need an interface for the application to indicate that an ephemeral port should be used?
It's implicit in the old socket API - accept just gives me a new socket, which I can use to continue communication, but I don't see the port numbers associated with this socket and never have to say that they are ephermal. I believe it's similarly implicit in ours. So ... what's missing?
The text above says "use an ephemeral port or generate an error". So when would you throw an error? If the assumption is that always an ephemeral port should be used (no matter actually how the underlying interfaces works) that should be stated (in the API doc).
If you do not use an "ephemeral port", and choose to specify the port - then you may get the error if it can't be completed.
... or if the system is out of resources for some reasons. Just like "accept" can fail in the normal socket API.
That too.
NAME requested that I adapt the "error" text in the implementation draft too. In doing so, I noticed: I don't understand NAME comment above, about choosing the specify the port. I think this kind of error was possible with sockets somehow, but this text talks about not specifying a Local Endpoint. Technically, I think not specifying a Local Endpoint yet specifying a port is not possible.Regarding my own comment, any call may fail for reasons such as the system being out of resources; I think mentioning this in the text here doesn't add any value though. As a result, I'll remove the part about the error from the text in my update to PR .
This seems like what was agreed.This change is fine. You also need to adapt the implementation doc to remove the "or" part: "either use an ephemeral port or generate an error."
Change:
Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs <del> below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively </del> <ins> below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively. </ins> If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in

Discussion:
[ section 4.4 ] "respectively" -> "respectively." Could a DTLS implementation packetize to a min-MTU for an IP version and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. [ section 4.5.3 ] "MUST NOT used" -> "MUST NOT be used" [ section 5.8.4 ] "NOT have send" -> "NOT send", I think [ section 6 ] "which are needed to encrypt to decrypt"?
and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. I'm reluctant to recommend this, given that we know one can run into situations where there is more overhead due to tunnels, etc.
Change:
7. <del> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Exporter Labels Registry as follows: </del> <ins> This document updates the registration procedure for the TLS Exporter registry and updates the Recommended column allocation.  IANA SHALL update the TLS Exporter Labels Registry as follows: </ins> <del> Update the registration procedure to include: </del> <ins> Change the registration procedure from Specification Required to Expert Review and update it to include: </ins> Add a reference to this document under the reference heading.

Discussion:
Update exporter
NAME minor nit, but this is what I remember being discussed in Philly.
I was recently surprised to learn that the uses . This is a problem for us - we have an internal use of an exporter that we cannot release a specification for at this time. This means that our only option is to "squat" on the value instead of registering it. Since we're already making changes to these repositories and we now have a Recommended column, I propose that we instead use . Note that Expert Review is exactly the same as Specification Required, with the exception that it doesn't require a specification. We could also add a requirement that entries with have a specification.
Change:
convenience functions to simplify use of Selection Properties: see preference-conv for examples.  In addition, implementations MAY provide a mechanism to create TransportProperties objects that are <del> preconfigured for common use cases as outlined in property-profiles. </del> <ins> preconfigured for common use cases, as outlined in property-profiles. </ins> Transport Properties for an established connection can be queried via the Connection object, as outlined in introspection.

Discussion:
The guidance applies to any connectionless transport.
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
LGTM
Change:
where messageData is the data object to send. <del> The optional messageContext parameter supports per-message properties and is described in message-props.  It can be used to identify send events (see send-events) related to a specific message or to inspect meta-data related to the message sent (see msg-ctx). </del> <ins> The optional messageContext parameter allows adding Message Properties as described in message-props.  Moreover, the messageContext can be used to identify Send Events related to a specific Message (see send-events) or to inspect meta-data related to the Message sent (see msg-ctx). </ins> The optional endOfMessage parameter supports partial sending and is described in send-partial.

Discussion:
Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message. If it does, the "reason" parameter can point to that message and/or a messageContext. The beginning of Section 7 actually already said that this IS the messageContext. I removed the word "implementation-specific" because to me this word made it sound like this reference can't be the messageContext. Split into two sentences and changed the second sentence to active voice. Also, I slightly reworded the beginning of Section 7, which is now a bit clearer in my opinion.
When reading the current API draft, I found three minor issues related to Message Contexts. The RendezvousError (Section 6.3) includes a messageContext (which is even required), but neither the InitiateError nor the ListenError include one. Why? Should this messageContext at least be optional?In Section 7.3, it says "The Sent Event contains an implementation-specific reference to the Message to which it applies." - Is this in addition to the messageContext? If yes, why do we need both?In Section 9, it says "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." - I think this sentence is a bit hard to parse and it wasn't immediately obvious to me what kind of framing meta-data this refers to. Perhaps this refers to Section 10.2, so I think it's worth adding a reference to that section here. Also, I suggest turning this into two sentences, with the sentence on framing meta-data specifying that this is per-Message metadata to be used by the framer.
Thanks a lot for doing this! It clears things up nicely, I think.
Change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> 4. [Editor's note: simplify this section and highlight DetNet MPLS over subnets scenario being the focus in the remaining part of the document.]. 4.1. </del> <ins> 3. </ins> <del> This document describes how DetNet flows are carried over MPLS networks.  The DetNet Architecture, I-D.ietf-detnet-architecture, decomposes the DetNet data plane into two sub-layers: a service sub- layer and a forwarding sub-layer.  The basic approach defined in this document supports the DetNet service sub-layer based on existing pseudowire (PW) encapsulations and mechanisms, and supports the DetNet forwarding sub-layer based on existing MPLS Traffic Engineering encapsulations and mechanisms.  Background on PWs can be found in RFC3985 and RFC3031.  Background on MPLS Traffic Engineering can be found in RFC3272 and RFC3209. The DetNet MPLS data plane approach defined in this document is shown in dn_mpls_dp_approach.  The service sub-layer is supported by a DetNet control word (d-CW) which conforms to the Generic PW MPLS Control Word (PWMCW) defined in RFC4385.  A d-CW identifying service label (S-Label) is also used. </del> <ins> The basic approach defined in I-D.ietf-detnet-mpls supports the DetNet service sub-layer based on existing pseudowire (PW) encapsulations and mechanisms, and supports the DetNet forwarding sub-layer based on existing MPLS Traffic Engineering encapsulations and mechanisms. </ins> A node operating on a DetNet flow in the Detnet service sub-layer, <del> i.e. a node processing a DetNet packet which has the S-Label as top </del> <ins> i.e.  a node processing a DetNet packet which has the S-Label as top </ins> of stack uses the local context associated with that S-Label, for example a received F-Label, to determine what local DetNet operation(s) are applied to that packet.  An S-Label may be unique when taken from the platform label space RFC3031, which would enable correct DetNet flow identification regardless of which input <del> interface or LSP the packet arrives on. </del> <ins> interface or LSP the packet arrives on.  The service sub-layer functions (i.e., PREOF) use a DetNet control word (d-CW). </ins> The DetNet MPLS data plane builds on MPLS Traffic Engineering encapsulations and mechanisms to provide a forwarding sub-layer that

Discussion:
Similar structure and changes as in IP over TSN. Service protection interworking is out-of-scope.
Change:
When processing header blocks, the decoder expects the Required Insert Count to exactly match the value defined in blocked-streams. If it encounters a smaller value than expected, it MUST treat this as <del> a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED; see invalid-references.  If it encounters a larger value than expected, it MAY treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. </del> <ins> a connection error of type QPACK_DECOMPRESSION_FAILED; see invalid- references.  If it encounters a larger value than expected, it MAY treat this as a connection error of type QPACK_DECOMPRESSION_FAILED. </ins> 2.2.2.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
100 <del> This property represents a hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </del> <ins> This property specifies the priority of a Message, relative to other Messages sent over the same Connection. </ins> A Message with Priority 0 will yield to a Message with Priority 1, which will yield to a Message with Priority 2, and so on.  Priorities

Discussion:
The text reads quire off when it says a priority property represents a hierarchy of priorities: This property represents a hierarchy of priorities. Could this better be: ‘A priority property is organised within a hierarchy of priorities. ‘?
When reading "hierarchy", it's easy to think that there may be priority sub-groups within priority groups, or something of that nature. Yet, this is not the case, it's just a flat priority assignment. Hence, to me, mentioning "hierarchy" here is misleading altogether. Therefore, I think we'd be much better off removing this sentence, i.e. replacing: with
Seems to resolving the odd wording.
Change:
Abstract This document describes a mechanism in Transport Layer Security (TLS) <del> for peers to provide a proof of ownership of a certificate.  This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. </del> <ins> for peers to provide a proof of ownership of an identity, such as an X509 certificate.  This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. </ins> 1. This document provides a way to authenticate one party of a Transport <del> Layer Security (TLS) connection to its peer using a certificate after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out-of-band from one party to be validated by its peer. </del> <ins> Layer Security (TLS) connection to its peer using a Certificate message after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out-of-band from one party to be validated by its peer. </ins> This mechanism provides two advantages over the authentication that TLS natively provides:

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
3.3.2. Censors sometimes identify entire protocols to be blocked using a <del> variety of traffic characteristics.  For example, Iran degrades the </del> <ins> variety of traffic characteristics.  For example, Iran impairs the </ins> performance of HTTPS traffic, a protocol that prevents further analysis, to encourage users to switch to HTTP, a protocol that they can analyze Aryan-2012.  A simple protocol identification would be to

Discussion:
…nce. defines censorship. fixes definition of identification in intro.
First, one thing that isn’t clear immediately from the introduction is who/what is a “censor”. I find it a little strange, actually, to suggest that a censor performs "aggregation". Is the censor an ISP? A government? Something else? For example, a government may have loose policies about what kind of content to censor (e.g., "hate speech"). An ISP might in turn implement these loose policies in different ways. Policies can also differ across a country, etc. The other terms---identification and prevention---are similarly confusing, although I think the term "identification" isn't as problematic as its (incorrect?) definition in the introduction. "Identification is the process by which censors determine whether content is blocked" - NO. I think it is the process by which a censor might classify traffic to determine whether to block a traffic flow or now. I would suggest something like: prescription, identification, and interference.
Wondering what you think about "design, identification, and interference"? I think for the purposes of todays 20:00 ET IETF drafts deadline, I'll change the terminology throughout to match prescription, identification, and interference and I'll correct the other things mentioned here (define censor, fix definition of identification in intro).
That seems a bit more clear, indeed! Ah, I didn't realize there was a deadline of today 2000h. Not sure I can get you a pull request by then, but will try.
I'll leave this open. You by no means need to get a pull request by 20:00! I just want to do my best to make changes responsive to your feedback. I'll leave this open and you can see what I've done (I'll be working on trying to clear out issues until then), and feel free to submit changes as you think are needed.