jiebi/CodeConvo huggingface dataset:
Change:
send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. <del> 8. </del> <ins> 9. </ins> QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established,

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
S/MIME receiving agents during certificate and CRL signature verification: <del> For 512-bit RSA with SHA-1 see RFC3279 and FIPS186-2 without Change Notice 1, for 512-bit RSA with SHA-256 see RFC4055 and FIPS186-2 without Change Notice 1, for 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For 512-bit DSA with SHA-1 see RFC3279 and FIPS186-2 without Change Notice 1, for 512-bit DSA with SHA-256 see RFC5758 and FIPS186-2 without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3279 and FIPS186-2 with Change Notice 1, for 1024-bit through 3072 DSA with SHA-256 see RFC5758 and FIPS186-3.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </del> <ins> For 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </ins> For RSASSA-PSS with SHA-256 see RFC4056. <ins> For ECDSA see RFC5758 and RFC6090.  The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For EdDSA see I-D.ietf-curdle-pkix and I-D.irtf-cfrg-eddsa.  The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </ins> 4.4. PKIX describes an extensible framework in which the basic certificate

Discussion:
Move the pointer to docs for historical algorithms to the historic appendix. Correct the fact that this is now a WG document.
Change:
can be conveyed to endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference. <ins> 5.3. The Key Distributor is responsible for knowing what users are allowed in a given conferences.  When the call setup signalling indicates a session from a particular endpoint and user wishes to join a conferences, the Key Distributor will tell the Media Distributor which conference to place that session in using a globally unique identifier for the conference that is sent, along with the relevant keying information, from the Key Distributor to the Media Distributor. </ins> 6. This framework, and the individual protocols defined to support it,

Discussion:
This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG
Change:
6.4.1. The order process described above presumes that authorization objects <del> are created reactively, in response to an application for issuance. Some servers may also wish to enable clients to obtain authorization for an identifier proactively, outside of the context of a specific </del> <ins> are created reactively, in response to a certificate order.  Some servers may also wish to enable clients to obtain authorization for an identifier proactively, outside of the context of a specific </ins> issuance.  For example, a client hosting virtual servers for a collection of names might wish to obtain authorization before any servers are created, and only create a certificate when a server

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD) defined in this document. </del> <ins> connection_id(TBD1) defined in this document. </ins> <del> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType </del> <ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType </ins> Registry".

Discussion:
URL If this PR is postponed to that date (12. April), may be the final values could be used. We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris
Change:
The entries in the registry are: The values in this registry shall be allocated under "IETF Review" <del> policy for values strictly smaller than 64, under "Specification Required" policy for values 64-223, and under "Private Use" otherwise (see RFC8126 for the definition of relevant policies). </del> <ins> policy for values strictly smaller than 256, under "Specification Required" policy for values 256-16383, and under "Experimental Use" otherwise (see RFC8126 for the definition of relevant policies). Experimental Use extensions can be used both on private networks and over the open Internet. </ins> The procedures for requesting values in the Specification Required space are specified in I-D.ietf-tls-iana-registry-updates.

Discussion:
It's been pointed out that one byte may not be sufficient to run experimental compression algorithms without collisions. Expand the space to 2^16 values, and update the IANA considerations section accordingly.
NAME suggested expanding the compression code point from 1 byte to 2.
Do we really want to do that? I can write up a PR, but I don't really see us ever having more than 20 of those... Old compression types took up only one byte; I expect us to have more, because dictionaries, but not much more, because realistically there are only so many codepoints we can deploy.
Since it was mentioned at the meeting I thought I create an issue so it can be discussed. I'm fine closing since I agree we probably don't need this, unless NAME or someone else has a reason for doing this (and we can reopen later if needed).
I suggested expanding this due to the potential future use of dictionaries. I agree we will likely never have more than 20 standardized code points, but 1 byte is a bit low for experimental use without worry of collision. 1 byte is probably enough, but 2 bytes would definitely be enough, and the cost of 1 extra byte seems pretty low to me.
Fixed in .
Added comment, otherwise lgtm.
Change:
Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senml and sensml </ins> Macintosh file type code(s): none

Discussion:
Why is there no sensml+cbor? (I can't really find where sensml+json is actually defined.) Is that really TODO?
sensml+json is defined in "Multiple Datapoints". Perhaps could be improved. That TODO was fixed in URL
That is an example, no? Where is the definition?
(In CBOR, SensML would just be a CBOR sequence. No need even for an array around that.) See also RFC 7464...
Change:
To get a fresh nonce, the client sends a HEAD request to the new- nonce resource on the server.  The server's response MUST include a Replay-Nonce header field containing a fresh nonce, and SHOULD have <del> status code 200 (OK).  The server SHOULD also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header). </del> <ins> status code 204 (No Content).  The server SHOULD also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header). </ins> Caching of responses from the new-nonce resource can cause clients to be unable to communicate with the ACME server.  The server MUST

Discussion:
The new-nonce endpoint added in defines a new endpoint which returns information just in headers, but with a 200 response code. I feel this would be more appropriate as a 204 No Content response code. I'm not sure what the approach to making this sort of change is. Should I create this change as a PR?
NAME A PR and a small note to the mailing list is probably the best approach. I'm not an HTTP status lawyer but it seems like 204 is the more-appropriate choice in this context and seems to agree with you: I would :+1: the PR to change to 204 for :-)
Change:
discussions. X2 embodies the physical-layer, applied to the PLFRAME, to <del> optimize the satellite capacity usage.  At the physical layer, FEC mechanisms can be exploited. </del> <ins> optimize the satellite capacity usage.  At the physical layer, other coding mechanisms can be exploited. </ins> Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques.  Based on public information,

Discussion:
John Border: Forward Error Correction (FEC) coding below the network layer takes us a long way. At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough. I do see that the referenced taxonomy document includes Forward Erasure Correction. This “FEC” is described as an application layer technique. The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers. In any case, it is not always clear which “FEC” the document is referring to.
I understand that there is some confusion on the usage of the accronym. We have clarified in the document that "Following the taxonomy document [RFC8406], channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." We have added in PR that this document considers FEC above the network layer.
Change:
response on a Retransmission Timeout (RTO) in TCP RFC5681 after Tail Loss Probes (TLP) RACK. <del> 6.8. </del> <ins> 6.9. </ins> This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the

Discussion:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!
Change:
of the CoRE link format RFC6690.  The target of the link MUST be a URI formatted string.  The client MUST indicate the desired content format for publishes to the topic by using the ct (Content Format) <del> link attribute in the link-format payload.  The client MAY indicate the lifetime of the topic by including the Max-Age option in the CREATE request. Topics may be created as sub-topics of other topics.  A client MAY create a topic with a 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 </del> <ins> link attribute in the link-format payload.  Additional link target attributes and relation values may be included in the topic specification link whena topic is created. The client MAY indicate the lifetime of the topic by including the Max-Age option in the CREATE request. 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 </ins> serialization, that topic may then have sub-topics created under it as shown in create-sub-fig.

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:
(described in hpke-config); see compliance for information about the HPKE configuration algorithms. <del> "vdaf_verify_param": The aggregator's VDAF verification parameter output by the setup algorithm computed jointly by the aggregators before the start of the DAP protocol VDAF).  [OPEN ISSUE: This is yet to be specified.  See issue#161.] </del> <ins> "vdaf_verify_key": The VDAF verification key shared by the aggregators.  This key is used in the aggregation sub-protocol (aggregate-flow).  [OPEN ISSUE: The manner in which this key is distributed may be relevant to the VDAF's security.  See issue#161.] </ins> The helper stores a bearer token used to authenticate HTTP requests from the leader.  Likewise, the leader stores a bearer token to

Discussion:
The next VDAF draft is out. It includes some minor changes that we'll need to adopt here. URL
Change:
The client MUST abort if any of the following happen for any HPKE config request: <del> the GET request failed or did not return a valid HPKE configuration; or </del> <ins> the GET request failed or did not return a valid HPKE config list; </ins> <del> the HPKE configuration specifies a KEM, KDF, or AEAD algorithm the client does not recognize. </del> <ins> the HPKE config list is empty; or no HPKE config advertised by the aggregator specifies a supported a KEM, KDF, or AEAD algorithm triple. </ins> Aggregators SHOULD use HTTP caching to permit client-side caching of this resource RFC5861.  Aggregators SHOULD favor long cache lifetimes

Discussion:
The current text is out-dated. Update it to account for multiple HPKE configs returned by the Aggregator.
Change:
Application Payload Security Protocols: <ins> DTLS when used as a handshake protocol for SRTP ZRTP </ins> SRTP Packet Security Protocols:

Discussion:
This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.
Change:
attestation defined by RATS is thus a candidate for use in the FIDO protocol. <del> Every FIDO Authenticator contains an Attester. </del> <ins> FIDO Authenticator. </ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information.

Discussion:
The current attester description in §2.7 is ambiguous and inconsistent with the earlier ones. Right now it reads: "Attester: Every FIDO Authenticator contains an Attester." To clarify and align the attested description with the earlier ones, I suggest replacing this text with: "Attester component contained in a FIDO authenticator".
Both definitions seem OK to me. The goal of the use cases isn't to provide a technical decomposition of the FIDO device IMHO. Rather, it is to provide a cursory level mapping to the abstract roles / role messages. In fact, if a change is needed I would simply have it say "Attester: FIDO Authenticator".
I agree that a technical decomposition is not the goal, however the current formulation just differs too much from the other ones. The change you suggested - "Attested: FIDO Authenticator" - is a good alternative.
"Attester: A FIDO Authenticator".
Change:
successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use <del> the same configuration by matching "KeyConfig.key_id" or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. </del> <ins> the same configuration by matching the key ID from the key configuration or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. </ins> Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active

Discussion:
This was the only case we used the TLS-style dot notation, but we don't need to pull in a new concept.
Change:
Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long headers carry <del> a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </del> <ins> a destination connection ID, a variable-length field which, if not zero-length, can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </ins> In version 1 of QUIC, the following additional information is exposed:

Discussion:
clarify why CID is present in all headers but is also optional... see issue
The text appears inconsistent to me: "Short headers contain only an optional destination connection ID""source and destination connection ID: short and long headers carry a destination connection ID", i.e., is it optional or not ? Also some inconsistency about the spin bit, is it only in v1 or is it an invariant ?
Change:
2.4. <del> QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection; that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. </del> <ins> QUIC connections are shared state between a client and a server QUIC- INVARIANTS.  The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection; that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. </ins> In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn)

Discussion:
editorial nit: for consitency with RFC 9000, consider changing you reference name from [INV] -> [QUIC-INVARIANTS]