jiebi/CodeConvo huggingface dataset:
Code change:
accounting. As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs <del> or tickets (and associated cached data) for longer than 7 days, regardless of the PSK or ticket lifetime.  The EAP-TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired.  In all such cases, an attempt at resumption results in a full TLS handshake instead. </del> <ins> or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime.  The EAP- TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired. In all such cases, an attempt at resumption results in a full TLS handshake instead. </ins> Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP

Related discussion:
text: URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".
Code change:
7.2. <del> A subdomain can also be used for all internal DNS names (e.g., the zone internal.example.com exists only on the internal DNS server). For successful validation described in this document the the internal DNS server will need a certificate signed by a CA trusted by the client. </del> <ins> In many split-horizon deployments, all non-public domain names are placed in a separate child zone (e.g., ).  In this configuration, the message flow is similar to internal- only, except that queries for hosts not within the subdomain (e.g., </ins> <del> For such a name internal.example.com the message flow is similar to internal-only the difference is that queries for hosts not within the subdomain (www.example.com) are sent to the public resolver rather than resolver for internal.example.com. </del> <ins> ) are sent to the external resolver rather than resolver for internal.example.com. As in internal-only, the internal DNS server will need a certificate signed by a CA trusted by the client. </ins> 8.

Related discussion:
text: Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.
Code change:
This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous <del> packet, or for codecs that support variable-bitrate encodings, </del> <ins> payload, or for codecs that support variable-bitrate encodings, </ins> possibly a smaller, lower-quality representation.  In certain cases, <del> the redundant data could include multiple prior packets. </del> <ins> the redundant data could include encodings of multiple prior audio frames. </ins> Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant

Related discussion:
text: It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.
Code change:
22. <del> Following is the list of changes from RFC 5245 </del> <ins> The purpose of this updated ICE specification is to: </ins> <del> The specification was generalized to be more usable with any protocol and the parts that are specific to SIP and SDP were moved to a SIP/SDP usage document I-D.ietf-mmusic-ice-sip-sdp. </del> <ins> Clarify procedures in RFC 5245. </ins> <del> Default candidates, multiple components, ICE mismatch detection, subsequent offer/answer, and role conflict resolution were made optional since they are not needed with every protocol using ICE. </del> <ins> Make technical changes, due to discovered flows in RFC 5245 and based on feedback from the community that has implemented and deployed ICE applications based on RFC 5245. </ins> <del> With IPv6, the precedence rules of RFC 6724 are used instead of the obsoleted RFC 3483 and using address preferences provided by the host operating system is recommended. </del> <ins> Make the procedures signaling protocol independent, by removing the SIP and SDP procedures.  Procedures specific to a signaling protocol will be defined in separate usage documents.  I-D.ietf- mmusic-ice-sip-sdp defines the ICE usage with SIP and SDP. </ins> <del> Candidate gathering rules regarding loopback addresses and IPv6 addresses were clarified. </del> <ins> The following technical changes have been done: Aggressive nomination removed. The procedures for calculating candidate pair states and scheduling connectivity checks modified. Procedures for calculation of Ta and RTO modified. Active check list and frozen check list definitions removed. 'ice2' ice option added. IPv6 considerations modified. Usage with no-op for keepalives, and keepalives with non-ICE peers, removed. </ins>

Related discussion:
text: The following issues are addressed in this commit: URL URL
LGTM
To prevent one check list from starving.
This was discussed (and, as far as I am concerned, agreed) on the list 1st June. But, it's good to have a reminder :)
This one has not been addressed as far as I can tell. Now we get to decided if it's important enough or not to do something about :)
I had a look at this, but for some reason it never got implemented. I think it should be an easy fix.
The changes section looks very small compared to how many changes we've made, so it definitely needs updating. Now we need to decide whether we have to update it before or after requesting publication.
Yes - we just have to remember everything :) However, I don't think we should go into details: the major changes (that I can think of when writing this) are removal of regular/aggressive nomination, and the changes related to "Emil's table".
LGTM
Code change:
7. <del> This section provides a summary on the content in previous sections. The fig:summary sums up some recommendations.  It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit.  Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del> <ins> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </ins> 8.

Related discussion:
text: This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.
Code change:
the delegation, even though they are not themselves authoritative data. <ins> "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone)." (Definition from RFC1912, Section 2.8) </ins> "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones].  These RRs are only necessary if the name

Related discussion:
text: We don't seem to have defined "lame delegation", which is a term that is used all the time. It's in RFC 1912. Should we add it?
Yes.
Code change:
octet of the Connection ID are reserved to express the length of the following connection ID, not including the first octet. <del> A server not using this functionality SHOULD make the six bits appear to be random. </del> <ins> A server not using this functionality SHOULD choose the six bits so as to have no observable relationship to previous connection IDs issued for that connection. </ins> 2.4.

Related discussion:
text: URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.
Code change:
To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout (PTO).  This allows for multiple PTOs to <del> expire, and therefore multiple probes to be sent in the event of loss, prior to idle timeout. </del> <ins> expire, and therefore multiple probes to be sent and lost, prior to idle timeout. </ins> 10.1.1.

Related discussion:
text: An update to I read the 4091 text as implying that probes were sent upon a loss.
Code change:
the RS again. The RS validates the access token and determines that the access <del> token is expired The RS responds to the client instance with an </del> <ins> token is expired.  The RS responds to the client instance with an </ins> error. The client instance calls the token management URI returned in (2)

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:
Code change:
Today, on the Internet it publishes two NS records, "ns1.example.com" and "ns2.example.com". <del> The host and network first need mutual support one of the mechanisms described in learning.  Shown in fig-learn is learning using DNR and PvD. </del> <ins> First, the host and network both need to support one of the discovery mechanisms described in learning. fig-learn shows discovery using DNR and PvD. </ins> <del> Validation is then perfomed using either example-verify-public or </del> <ins> Validation is then perfomed using either example-verify-external or </ins> example-verify-dnssec. 7.1.1. The figure below shows the steps performed to verify the local claims <del> of DNS authority using a public resolver. </del> <ins> of DNS authority using an external resolver. </ins> 7.1.2.

Related discussion:
text: Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.
Code change:
would be too large to fit in a packet, however receivers MAY also limit ACK frame size further to preserve space for other frames. <del> When discarding unacknowledged ACK Ranges, a receiver MUST retain the largest received packet number.  A receiver SHOULD retain ACK Ranges containing newly received packets or higher-numbered packets. </del> <ins> A receiver MUST retain an ACK Range unless it can ensure that it will not subsequently accept packets with numbers in that range. Maintaining a minimum packet number that increases as ranges are discarded is one way to achieve this with minimal state. Receivers can discard all ACK Ranges, but they MUST retain the largest packet number that has been successfully processed as that is used to recover packet numbers from subsequent packets; see packet- encoding. A receiver SHOULD include an ACK Range containing the largest received packet number in every ACK frame.  The Largest Acknowledged field is used in ECN validation at a sender and including a lower value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see ecn-validation. </ins> A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of

Related discussion:
text: In that mental model, at least, there's not really room for the idea that you might drop the largest-acked frame number from your memory because it's too old -- it's always at the most-recent end of your chain, even if you currently happen to be receiving packets that fill in the middle for some implementation-specific reason. (Implementation-specific to the peer, which you obviously can't know about or code for!)
That matches my model for this. It is also likely the case that the next packet you receive is largest+1, so there is no real advantage to forgetting the largest acknowledged. Not sending largest acknowledged is slightly different though. I can understand how an implementation might choose to send only ranges that have recently changed. My contention is that this is not a good choice and we should recommend against that.
NAME to produce some text here that separates retention policy (MUST) from signaling policy (SHOULD).
Code change:
The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the <del> peer.. </del> <ins> peer. </ins> Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake.

Related discussion:
text: Need to address and directorate reviews.
Correction ARTART editorial are addressed via and .
and .
Also noted in ARTART review. Reviewer: Christian Amsüss Review result: Ready with Nits Thanks for this well-written document ART topics: The document does not touch on any of the typical ART review issues; times are relative in well understood units, and versioning, formal language (ASN.1, which is outside of my experience to check) and encoding infrastructure (struct) follows TLS practices. General comments: The introduction of this mechanism gives the impression of a band-aid applied to a PKI ecosystem that has accumulated many limitations as outlined in section The present solution appears good, but if there is ongoing work on the underlying issues (even experimentally), I'd appreciate a careful reference to it. Section 7.6 hints at the front end querying the back-end for creation of new DCs -- other than that, DC distribution (neither push- nor pull-based) is discussed. If there are any mechanisms brewing, I'd appreciate a reference as well. Please check: The IANA considerations list "delegated_credential" for CH, CR and CT messages. I did not find a reference in the text for Ct, only for CH and CR. Editorial comments: (p5) "result for the peer.." -- extraneous period. (p9, p15, p16) The "7 days" are introduced as the default for a profilable prarameter, but later used without further comment.
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Just a few editrial level nits. Major issues: None Minor issues: None.
Code change:
The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the <del> peer.. </del> <ins> peer. </ins> Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake.

Related discussion:
text: Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expectedcertverify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:"
Code change:
Application messages <del> The sender information used to look up the key for the content encryption is encrypted under AEAD using a random nonce and the "sender_data_key" which is derived from the "sender_data_secret" as follows: </del> <ins> The sender information used to look up the key for content encryption is encrypted with an AEAD where the key and nonce are derived from both "sender_data_secret" and a sample of the encrypted message content. </ins> For handshake and application messages, a sequence of keys is derived via a "sender ratchet".  Each sender has their own sender ratchet,

Related discussion:
text: Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by
Code change:
consider congestion control aspects when proposing coding solutions. The proposed recommendations apply for coding at the transport or <del> application layer and coding for tunnels is out-of-the scope of the </del> <ins> application layer.  Coding for tunnels is out of scope for the </ins> document. 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward <del> Erasure Correction (FEC) channels.  Congestion Control channel carries data packets (from the server to the client) and a potential </del> <ins> Erasure Correction (FEC) channels.  The Congestion Control channel carries data packets (from a server to a client) and a potential </ins> information signaling the packets that have been received (from the <del> client to the server).  Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del> <ins> client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. Inside a host, the CC and FEC entities can be regarded as conceptually separate: As this diagram shows, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/ lower rate bounds, periods of quiescence, or a priority. It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa - information about repaired blocks may be quite irrelevant to a CC algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their own raw inputs.  For example, the network measurements carried out by CC can yield a longer-term statistical measure such as a loss ratio which is useful input for a FEC coding scheme.  Similarly, unequal error protection using fountain codes can be used to assign different priorities to blocks of data, and these priorities can be honored by a CC mechanism. </ins> 3.

Related discussion:
text: This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.
Code change:
length is a uint defined by the application <del> PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. </del> The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same

Related discussion:
text: I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.