jiebi/CodeConvo huggingface dataset:
Change:
cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the <del> protocol is explicitly disallowed. </del> <ins> protocol is not allowed. </ins> Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
matching regexp is needed in a data model specification or a query language expression. <del> A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  With certain exceptions as discussed there, these should be covered by I-Regexps, both syntactically and with their intended semantics. </del> <ins> The editors of this document conducted a survey of the regexp syntax used in published RFCs.  All examples found there should be covered by I-Regexps, both syntactically and with their intended semantics. The exception is the use of multi-character escapes, for which workaround guidance is provided in mapping. </ins> 3.

Discussion:
Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.
Change:
timer to the initial value.  One situation where this might occur is when a rehandshake is used after substantial data transfer. <del> 5.7. </del> <ins> 5.8. </ins> CertificateVerify and Finished messages have the same format as in TLS 1.3.  Hash calculations include entire handshake messages,

Discussion:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?
Change:
Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". <del> 6.2. </del> <ins> 6.4. </ins> IANA is requested to add "srtp_ekt_message" as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer

Discussion:
Should be in EKTkey not where it is. Should have text that when grt new KEK, need to wait X then start using new SRTP master key
Change:
storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully <del> inspected. </del> <ins> inspected to match a policy that applies to this network and is correctly processed by the leaves. </ins> The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different

Discussion:
…S and COMMENT) On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (pthubert=EMAIL) wrote: Hello Michael and all: Yes, I expected policies that would validate the right of a Leaf to participate to a DODAG ,or to remap the information from the leaf (could be the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI. Yes, as I said in my response I thought it was quite common. I'm surprised to find little art to quote. Cool, we're good! Pascal Roll mailing list EMAIL URL Roll mailing list EMAIL URL
Change:
request-examples Example 1. The registrar validates the client identity as described in EST <del> RFC7030 section 3.3.2.  If the request is signed the registrar confirms that the associated 'proximity-registrar-cert' is correct. </del> <ins> RFC7030 section 3.3.2.  The registrar confirms that the 'proximity' assertion and associated 'proximity-registrar-cert' are correct. </ins> 5.3.

Discussion:
This should be a complete set of diffs for removing unsigned pledge voucher-requests from the text.
For issue
The text "This artifact may be optionally signed" is buried in the yang module (ietf-voucher-URL) and needs to be removed.
When a pledge decides to use an unsigned voucher request, the Registrar will place it into prior-signed-voucher request on the BRSKI-MASA arc. It will be JSON embedded in. When a pledge decides to use a signed voucher request, the Registrar will place the base64 encode of the pledge_request in as a string. The MASA can tell the difference between the two because the signed thing (whether CBOR, COSE, CMS signed CBOR, or CMS signed JSON) will always be base64 encoded. We need to explain this somewhere.
section 5.5 indicates that: prior-signed-voucher-request: If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher- request. (NOTE: what is included is the complete pledge voucher- request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This indicates that the MASA never needs to "tell the difference" only the registrar. (The pledge to registrar signaling is via request media type as detailed in s5.2). I did notice this when reading: s3.3. these references to voucher in the leaf description should be to voucher request? "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field." etc. subsequent paragraphs.
URL tries to fix the lack of specification for unsigned voucher requests.
Max to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this.
v20 of BRSKI removed unsigned voucher requests. What were the reasons for removing? I don't see a mention of this in the anima WG email. If removed as a final decision, then this issue can be closed also.
Hi, yes, we could close this now. I did post several times to the list in Feb and March, and it was raised during the WG meeting itself, asking for feedback.

Ok, I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed.
Change:
Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> property to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver's mid property, following the guidance for "a=mid" mentioned in sec.initial-offers. </del> <ins> property to the MID of the m= section, and establish a mapping between the transceiver and the index of the m= section.  If the m= section does not include a MID (i.e., the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in sec.initial- offers. </ins> For each specified media format that is also supported by the local implementation, establish a mapping between the specified

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
This is a list of the cryptographic options supported by the client, with the client's first preference first.  Values are <del> defined in the-cipher-suite. </del> <ins> defined in cipher-suites. </ins> Versions of TLS before 1.3 supported compression and the list of

Discussion:
This revises "The Cipher Suites" section to simplify redundant language, actually explain the de facto naming convention, and add all currently available AEAD cipher suites. It also drops the appendix table that has already had its section whittled down quite a bit, in favor of the explanation and new table in the main section. Note that this is all of the AEAD ciphers available in the current IANA registry [0], plus ChaChaPoly (which has to be a normative reference [1], so must reach RFC status before this does). Issue just said "standards track AEAD ciphers", but as the registry lists them all, adding them wasn't difficult. If we'd rather not cite them here then they can of course be cut out (ARIA, Camellia, & ECDHE AES-CCM are informational; the rest are standards track, including DHE AES-CCM). Alternatively, the table could be annotated to note which are on what track or split in two. This has no changes to any requirements. [0] URL [1] URL
NAME I addressed your comments in this new commit. I switched to a table to make things easier to read and explicitly clarified the constant string bits so as to be more clear. I also dropped the confusing sentence fragment.
looks good.
AES-OCB will also be addable to this list, but its codepoints are all completely TBD still. URL
Rebased, squashed, & updated for recent changes to draft.
Ok, all comments addressed with that last commit. I've split the table into standards and non-standards and simplified the note to just mention ECDHE AES GCM being widely deployed.
Rebased.
Ok, reworded that bit too.
I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.
NAME This was dealt with in PR and can be closed.
Change:
used for ICE restarts, it will contain a new ICE ufrag/pwd pair. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. <del> If both Trickle ICE or ICE restarts are not supported by the WHIP resource, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request.  If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 501 Not Implemented for the HTTP PATCH requests that are not supported. </del> <ins> If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 405 (Not Implemented) for the HTTP PATCH requests that are not supported.  If the server does not support the PATCH method for any purpose, it returns a 501 (Not Implemented), as described in RFC7231 section 6.6.2. </ins> As the HTTP PATCH request sent by a WHIP client may be received out- of-order by the WHIP resource, the WHIP resource MUST generate a

Discussion:
As per discussion during IETF WISH meeting
thank you for the PR Adam! One further question, I think we should consistently use the return code and reason phrase styling across the document. what would be best? 200 OK 200 "OK" 200 (OK)
Change:
implemented by some implementations according to an earlier, pre- standard definition (in which, for example, no "m=" sections were marked as bundle-only).  As a result, "max-bundle" is considered <del> deprecated, and new applications should use the "must-bundle" policy instead. </del> <ins> deprecated, and implementations compliant with this specification SHOULD ignore attempts by the application to select this bundle policy (although some phase-out period may be necessary to avoid application breakage). </ins> The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies:

Discussion:
Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout
Change:
A CoAP endpoint (or proxy) MUST support either both or neither of the Q-Block1 and Q-Block2 Options. <ins> If Q-Block1 Option is present in a request or Q-Block2 Option in a response (i.e., in that message to the payload of which it pertains), it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed. </ins> To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request, the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs
Change:
and the validation key material off the device.  Sometimes this is procedure is referred to as personalization or customization. <ins> 12.1.2.1. </ins> One way to provision key material is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality protection of the generator, as well as for the path

Discussion:
and
A few words on the “why that is the case” are needed here.
Both examples basically seem to be the same here?
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document defines requirements on future QUIC versions, even where normative language is not used.

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document defines requirements on future QUIC versions, even where normative language is not used.

Discussion:
kramdown-rfc2629 inserts a non-breaking space when expanding , which xml2rfc subsequently mangles to produce invalid XML. Rather than deal with that, insert the boilerplate with regular spaces instead. Note that this is necessary to make work properly, as that tool drops the non-breaking whitespace character between "BCP" and "14".
URL (I need to follow up regarding the use of non-breaking whitespace generally).
This seems fine, but I assume you've separately filed the appropriate bugs to fix the regular tools?
Change:
The TokenRequest contains a supported token_type. <del> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. </del> <ins> The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of a Public Key owned by the issuer. </ins> The TokenRequest.blinded_request is of the correct size.

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2) <del> a URL for the Captive Portal Server.  The API SHOULD provide evidence </del> <ins> a URI for the Captive Portal Server.  The API SHOULD provide evidence </ins> to the caller that it supports the present architecture. When User Equipment receives Captive Portal Signals, the User

Discussion:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.
Change:
4.2. This section covers required behavior of a TSN-aware DetNet node <del> using a TSN sub-network. </del> <ins> using a TSN sub-network.  The implementation of TSN packet processing functions MUST be compliant with the relevant IEEE 802.1 standards. </ins> From the TSN sub-network perspective DetNet IP nodes are treated as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
The ACME client periodically contacts the CA to get updated certificates, stapled Online Certificate Status Protocol (OCSP) <del> responses, or whatever else would be required to keep the web server functional and its credentials up to date. </del> <ins> responses RFC6960, or whatever else would be required to keep the web server functional and its credentials up to date. </ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the

Discussion:
Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.
Change:
count once requests like "/books/{id}" <del> count twice search requests like "/books?author=Camilleri" </del> <ins> count twice search requests like "/books?author=WuMing" </ins> so that we have the following counters

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer <del> MAY associate the 4-tuple with the decision.  This has two advantages: </del> <ins> MAY associate the 4-tuple or connection ID with the decision.  This has two advantages: </ins> <del> The load balancer only extracts the server ID once per incoming 4-tuple.  When the CID is encrypted, this substantially reduces computational load. </del> <ins> The load balancer only extracts the server ID once until the 4-tuple or connection ID changes.  When the CID is encrypted, this might reduce computational load. </ins> Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server.

Discussion:
The '11' codepoint might be better defined. It would be good, for instance, if a stateful load balancer actually stored the observed CID so that the connection can survive a NAT rebinding.
Actually this is a bit harder than we'd like. If the load balancer is stateless, then the short-header processing would have to be based on the destination connection ID to be robust to NAT rebinding. But then, as the connection ID will change mid-handshake, long-header processing needs a different approach. I don't see how, logically, a stateless LB can maintain consistency between these two results unless we force the unconfigured server to retain most of the client-generated CID.
Having reflected on this a bit more, this is what I think we should do: Keep 0b11 as 4-tuple routing. However Load Balancers MAY observe destination connection IDs and keep state on them, to later survive a NAT rebinding. I see two use cases for 0b11: (1) a general purpose server that always uses QUIC-LB, whether or not it's behind an LB, for simplicity. So when it's not behind a Layer 4 LB it just generates random CIDs except for the first byte. As an added bonus, if there is an unknown L4 LB in front of it the behavior will not be pathological, at least until there's a migration. But in general, the rebinding performance is not all that important. (2) As a panic mode when things are misconfigured or the server has run out of nonces. Again, I'm not sure rebinding performance is super-critical. In other words, if a server is behind an L4 load balancer is and is using 0b11, something has gone very wrong.
Change:
4.1. <del> We define a new X.509 extension, DelegationUsage to be used in the </del> <ins> We define a new X.509 extension, DelegationUsage, to be used in the </ins> certificate when the certificate permits the usage of delegated credentials.

Discussion:
Based on One of the design criteria for this standard is to isolate the TLS with the DC extension from other protocols. In this PR, I propose explicitly restricting the X.509 KeyUsage of the end-entity certificate. This change is made in the last commit: URL The two commits that proceed it don't actually change the semantics of the standard, but clean up the language a bit. If the KeyUsage change isn't adopted, we might consider merging the other two commits.
if it's not too painful, could you move this particular diff above all the others, I think I want to have some more discussion on this one. If its painful, we can just resolve this one first
Done, NAME
looks like i merged this as a result of merging a dependent PR accidentally. This is fine, we can just discuss this before I put up the next draft versions
Change:
symmetry of a flow (whether primarily client-to-server, primarily server-to-client, or roughly bidirectional, as input to basic traffic classification techniques) can be inferred through the measurement of <del> data rate in each direction.  While QUIC traffic is protected and ACKs may be padded, padding is not required. </del> <ins> data rate in each direction.  Note that QUIC packets containing only control frames (such as ACK-only packets) may be padded.  Padding, though optional, may conceal connection roles or flow symmetry information. </ins> 3.8.

Discussion:
URL I am not sure what does the last sentence supposed to add to the context and see it is something more important for the applicability part than manageability part.
I already clarified the sentence in PR related to issue . Or is this the wrong reference?
ok, fine with me.
URL, padding and padding frames have been discussed/mentioned several times but I haven't got a clear indication on what does the padding to the manageability. Please point me to the description if I am mistaken.